OPNsense Firewall for your Magento Shop Infrastructure

1. Why a network firewall at all?

To understand why your Magento infrastructure needs a network firewall like OPNsense, it's worth first looking at what knocks on your shop's door all day long: internet traffic.

That has long been about far more than just real customers. Mixed in are search-engine bots, security scanners, brute-force attempts, known malicious IPs, spam bots and plenty of background noise. And this is no fringe phenomenon: according to the Imperva Bad Bot Report 2025, by 2024 more than half of all global web traffic was already automated (51%) — for the first time more than human traffic. A good third (37%) comes from outright malicious bots, and Germany is among the most heavily affected countries worldwide.

Whether a given bot is good or bad can't be said across the board — it depends on your shop: Googlebot is welcome, a competitor's price scraper rather less so. With IP addresses the picture is clearer. Which addresses are malicious is largely known and documented across the net — and it's precisely this known, malicious portion that's responsible for a substantial share of load and resource consumption, long before a real visitor is even served.

2. Why doesn't the host simply take care of this?

It could — technically rather easily, in fact. But it deliberately doesn't: a content-based filtering of your traffic would be an intervention that's legally delicate from a data-protection standpoint and isn't part of its role. What is an attacker to one shop can be a legitimate visitor to another.

That's why the host limits itself to what only it can do: intercepting volumetric DDoS attacks — the brute force that completely clogs your line or the switch port. Exactly where your own firewall, whichever one it is, could no longer do anything anyway, because the bandwidth itself is already saturated. Everything finer remains your job.

3. Good and bad IPs — not all that complicated

Before OPNsense can filter, you have to define what a good and what a bad IP is. That sounds more laborious than it is, because others have long since done this work. There are established reputation lists — Spamhaus, AbuseIPDB, IPsum and plenty more. The non-profit Spamhaus Project, for instance, doesn't just generate its entries automatically but has them vetted by a dedicated team of researchers and forensics specialists — and is used by ISPs, email providers, authorities and corporations worldwide. Such lists partly overlap, but taken together they add up to a reliable picture.

Most work with a confidence measure: AbuseIPDB, for example, with a score from 0 to 100 (0 = inconspicuous, 100 = reported as malicious by many users), IPsum with a level that counts how many of its more than 30 evaluated blacklists an address appears on simultaneously — the higher, the clearer the case. So you decide for yourself at which threshold blocking happens. The scale behind this is considerable: AbuseIPDB alone processes over one million abuse reports per day.

In OPNsense you register such lists as a URL-table alias — the firewall pulls them automatically and keeps them up to date. Most lists are free; AbuseIPDB becomes paid from 10,000 entries onward and doesn't supply its data in a directly importable form. That's exactly what our PARC Security container is for: it fetches the AbuseIPDB data, prepares it and makes it available to OPNsense ready to import.

The result: a large part of the known malicious traffic is sorted out right here — at the network level, long before it costs compute time in the subsequent layers or does any damage.

4. Clear boundaries — outward, inward and in between

The second major task of OPNsense is separating the public from the internal network. OPNsense is the only component that public traffic ever reaches directly — none of your virtual machines, no cache, no app, no database, sits unprotected on the open internet.

Here default-deny applies: by default all ports to the public network are closed; open are only the mandatory ports 80 and 443 for web traffic. That doesn't mean that SSH, SFTP & co. don't work — they're just not reachable from the open internet, but exclusively via VPN or for defined, trusted IPs. With that, the most common brute-force attack surface simply disappears.

This boundary works in both directions. Because why would the internal VMs ever need to reach out to the open internet of their own accord? Apart from pulling updates: practically never. That's why outbound traffic is filtered too — a VM may only reach the addresses and ports outward that it really needs, everything else is closed. Should a backdoor ever slip in, it can neither receive commands from a control server nor let stolen data flow out — it's stuck in a dead end.

And the isolation doesn't end at the VM boundary, it reaches into every single machine. Each VM is hardened in itself: a minimal installation with only the one service it provides, a firewall directly on the VM itself that opens exclusively the ports actually needed (plus the update channel), and fail2ban, which also monitors the internal traffic. Everything else is already closed on the machine — not just on the network firewall. If an attacker overcomes one layer, they immediately face the next.

The principle of "one service per VM" pays off well beyond security. Where only a single application runs, there are hardly any package conflicts, mutual dependencies or side effects: updates can be applied in a targeted way and, in case of doubt, just as specifically rolled back, without half a dozen other services being affected too. The complexity of a single machine drops drastically — and with it the likelihood that an update knocks over something unexpected. The same separation is also the basis for each service being able to scale, move, back up or be laid out for high availability independently.

This staggered, multiply-secured design is no PARC special path, but recognised security doctrine — it follows the defence-in-depth principle that the BSI also describes in its IT-Grundschutz. We deliberately go beyond what a single central firewall can deliver:

Summary of the security measures protecting your Magento infrastructure

• Volumetric DDoS protection at the host level
• IP reputation filtering from continuously updated blacklists
• Default-deny outward — only 80/443 open
• Egress control — no uncontrolled traffic outward
• Strict network separation — no VM directly on the open network
• Internal segmentation — services reachable only on their ports
• Host firewall on every VM — isolation right into the machine
• fail2ban — for internal traffic too
• Minimal installation — one service per VM, small attack surface
• Admin access only via VPN — no open SSH port on the network
• TLS termination only at the WAF — content inspection before the app
• High availability — failover safety at every level

That is exactly the difference between "a firewall stuck in front" and a thoughtfully secured infrastructure.

5. Why OPNsense specifically?

There are several mature open-source firewalls: in the FreeBSD camp OPNsense and pfSense (closely related — OPNsense emerged in 2015 as a fork of pfSense, which in turn came out of m0n0wall), in the Linux camp IPFire. The decisive factors for us were the following points:

• Independent governance. Developed by the Dutch manufacturer Deciso, the open-source core is fully usable, the roadmap transparent, the release cadence predictable — two major versions per year, with regular patches in between.
• API-first. A complete official REST API, the entire configuration as versionable XML. Setup, updates and recovery run automated and reproducibly instead of via a click marathon — infrastructure as code.
• Native blacklist integration. Reputation lists via URL table, automatically synced — the basis for the IP filtering from above.
• WireGuard in the kernel. Plus OpenVPN and IPsec — for secured access: administration, site-to-site coupling, connecting external services and more.
• GeoIP filtering. Selectively block or allow traffic at the country level.
• High availability. Two (or more) devices can be coupled via CARP into a failover cluster with a shared virtual IP. If the primary fails, the second takes over within seconds — and because the connection table is continuously replicated, existing connections are preserved.
• Reporting in the core. Traffic statistics and NetFlow without additional tools.
• 2FA & role-based access. Clean operation when several hands are to work on the system.
• Modern web interface. Tidy and clear.

6. Sized correctly — lean instead of over-engineered

A network firewall doesn't have to be big to be fast — it has to be properly tailored. The decisive point: with us, OPNsense only carries the lightweight tasks — forwarding packets, blocking known IPs and ports, terminating VPN. These are network-level operations that cost barely any compute power. The truly compute-intensive work — decrypting TLS and inspecting the content of every request — deliberately happens only on the downstream WAF, not here. That keeps OPNsense lean.

With pure packet filtering the bottleneck isn't the number of CPU cores, but the single-core performance and the network card. The memory requirement is low: each active connection occupies roughly 1 KB in the state table — so even 500,000 simultaneous connections are only about 500 MB of RAM. A double-digit number of gigabytes of RAM and a modern CPU with few, but fast cores already cover very large loads.

Because the requirement is so manageable, OPNsense is flexible in operation. It runs on dedicated hardware just as well as a virtual machine — for instance on a Proxmox host alongside other services or in the cloud with shared resources. Dedicated CPU cores are no must; they're sensible above all when constant latency under load is to be guaranteed — then you pin the firewall to fixed cores so that a noisy neighbour on the same host doesn't slow it down. With mass storage, speed isn't what counts, only that it's present: OPNsense occupies just a few gigabytes, and firewalling is no I/O-heavy process — a normal SSD is plenty, NVMe brings no measurable advantage. Only the logs are written continuously; on robust server storage that's uncritical, and anyone wanting to be maximally gentle puts the log directory into memory (RAM disk) with a click. This is really only a wear issue with small embedded appliances using flash storage, not with a VM on proper server storage.

Concretely, OPNsense states as its minimum requirement a 1-GHz dual-core CPU and 3 GB of RAM; recommended are a 1.5-GHz multi-core CPU with 8 GB of RAM and an SSD. This recommended setup, according to the manufacturer, already covers 350–750 Mbit/s and over a hundred users or networks — and that with the full feature set. In practice we typically give our OPNsense VM 2 cores and 8 GB of RAM; even with 4 GB it would run fine for the pure edge task (filtering, blocking, VPN). It simply doesn't need more, as long as the compute-intensive content inspection sits on the WAF.

The whole thing is usually run virtualised with shared resources — that's cheap, flexible and entirely sufficient for this load. If a single server eventually no longer suffices, you simply add further dedicated servers and scale horizontally. In reality, though, with a well-sized setup you only very rarely grow beyond the resources of a single dedicated server.

What this means in practice can be pinned to the connection bandwidth. A leanly built Magento site is surprisingly light: a real product page optimised with Hyvä transfers completely — HTML, CSS, JavaScript and all images — only around 250 to 300 KB. That's about one tenth of what an average web page weighs, and exactly the kind of leanness that benefits loading times and search-engine ranking. Reckoning conservatively with 300 KB per request, the theoretical upper limit of the line works out as:

• 1 Gbit/s connection. ≈ 125 MB/s — arithmetically over 400 page deliveries per second, i.e. headroom for more than one million page views per hour.
• 10 Gbit/s connection. ≈ 1,250 MB/s — tenfold, several thousand pages per second, for very large shops or extreme load peaks.

In practice the connection is therefore almost always the limiting factor, not the firewall itself — it has ample reserves for its task.

The figures given are indicative of the order of magnitude. The actual page size depends heavily on the particular shop — theme, number of images, number of products per page — and can in individual cases be significantly higher or lower. They don't replace a concrete load measurement, but give a realistic sense of the dimensions.

What gets through as web traffic on ports 80 and 443 is thereby cleaned of known attackers — but not yet inspected for content. OPNsense can't do that at this point at all: to look inside the content of encrypted connections, the traffic would first have to be terminated, i.e. decrypted, here. The firewall deliberately doesn't do exactly that. The TLS termination, and with it the content inspection at the application level, is handled only by the downstream SafeLine WAF.

Contact us