This is how I’ve structured my home network for somewhere over a decade and I’ve been pretty happy with it.
Setup is approximately as follows:
Internet -> dedicated BSD box w/ pf -> Linux boxes w/ netfilter
The idea being a single networking stack exploit can rip right though a network if the entire network uses the same network code.
Unfortunately, while Linux is popular, it’s also a gigantic pile of complicated C code running in kernel space.
Naturally this has a higher learning burden, having to learn how to configure two different operating systems creates more opportunities for misconfiguration. I suspect this is offset though two factors - I find BSD docs and books to be higher quality, and in order to write accidentally too permissive rules requires screwing up both a pf and nftables ruleset, which work notably differently (last match vs first match wins, amongst other details).
Some amount of Linux firewall/router duties may be offloaded to hardware acceleration, if enough of it was offloaded that would count as a second implementation.
It also increases your attack surface by exposing you to security issues in both Linux and BSD. Running multiple kernel/OS adds a lot of extra complexity, and it can be difficult to have the same level of knowledge in all system.
I do run OPNSense/FreeBSD as my firewall, and all my servers are Linux, but it is mostly because I think it’s a good firewall.
Somewhat, but I don’t think it’s very significant. That BSD has an attack surface and that it might get owned is part of the thinking.
The way I see that approximately if the BSD router does fall these two pictures aren’t hugely different:
Malicious Internet -> Linux -> Linux
Malicious Internet -> Malicious BSD -> Linux
I think you’ve added a lot of vulnerability surface that isn’t present if you’re following this kind of thinking. We are open to the Internet facing router getting rooted at some point, that’s why we are picking something with a different set of 0days. Under that thinking you’re not going to have management interfaces, samba etc al accessible to the router.
This thinking overlaps with some of (poorly named IMHO) “zero trust” architecture, just being on the same LAN does not make you trusted.
In the very small diagram, the Linux boxes all have host based firewalls configured. (I solve the challenge of how do you trust the IPs referenced in firewall rules by using wg authenticated IPs but there are other ways).
If you mean it’s less likely for a single vulnerability to KO your entire setup, I agree. That’s one of the reasons I run all major desktop OSes with separate backup systems for each too.
My gateway is UniFi, UniFi OS Server runs on my Mac Mini, my IDS is ProofPoint, my DNS is Pi-hole + unbound on Debian, my VPN is Wireguard on Kubuntu, and my WANs are fiber and 5G.
I’m by no means impenetrable, but the loss of any one of those things won’t take me offline for too long.
That might be true for you, but most people will have DMZ and LAN networks protected by the firewall, and an attacker being able to control the firewall would be a huge problem.
If you only look at security issues in the kernel network stack, the difference is that packets will move first through BSD and then Linux, and there will be the possibility to exploit issues in both kernels.
Routing the traffic through multiple systems is going to protect you from some attacks, but it is also going to expose you to new attacks.
Don’t get me wrong, I’m not saying you shouldn’t use a BSD-based firewall, and systems like OpenBSD are more secure than Linux.
We’ve had this discussion where I work - in a different form:
run different OS on the firewall to your interior
run different edge firewall and internal firewall make/model
thinking being as above - if someone has an exploit for edge firewall, they own the inside firewall easily.
At some point though it’s a trade-off between management hassle and security.
we’ve definitely had discussions (initiated by myself) regarding heterogenous end user compute - thinking being that if everybody is on the same platform they’re all screwed by teh same exploit if one gets in.
probably also makes sense to run a different OS on your servers to your end devices too…
Not immediately. Unless both are exposed to the same threads. Something needs to get through the exterior firewall first, at which point its exploit for that doesn’t work on the second layer behind it on a different platform.
hopefully.
well… put another way in maybe clearer language:
it increases your vulnerabilities to patch
it does increase the number of exploits an attacker needs to work to take everything.
It might add a small delay or a little recon time - likely if they’ve rooted your firewall undetected (otherwise they would’ve been stopped) and gained a foothold they are going to survey the playground and come up with a strategy.
I would argue however that edge firewalls above consumer junk shouldn’t be that much of a concern this day and age. Client devices are the bigger risk - especially coupled with lateral movement. Here I think diversity would matter the most when possible.
There’s no reason any service of the firewall should be exposed to the internet in 2026. Any open ports should be NAT / Port forwarded to a service. Your firewall should not do any web serving (reverse proxying) / VPN Services (the 90s are 30 years ago) or any other such service. For all intents and purposes it should be a black box.
Opnsense/pfsense or something else - seen arguments about ”needing to know about different kernels” - I do not find that as a valid argument - The risks get spread out, and usually you never compile the parts yourself for all os:es or functions, you rely on the maker.
