Routing domains, or VRFs, are probably easiest to think of like VLANs, but one layer up.

The two typical scenarios are;

1. You want to use the same IP space multiple times across different networks (i.e. multi-tenant)

2. You have a bunch of different networks that you really never want to ever be able to talk to each other (you can allow it through routes, etc. but by default this does not happen). Although you can achieve this with VLANs and ACLs, on a single routing table, rules can become a real pain in the ass to manage very quickly

You could use this for stuff like guest or IoT networks.

Thanks for the great intro. I do segregate my network using vlans now to isolate things like my printer which I don't trust and also my guest network. I also isolate my wife's devices as I don't generally trust Windows being behind my firewall either.

I'm currently wrangling with a good solution for selectively routing certain traffic via one of multiple VPN connections I have on my router.

I'll look into rdomains to see if this may help my situation if not only to make it more simple.

I used to do this with pfsense to route all traffic from a specific internal IP over a VPN. If I remember rightly I set up multiple VPN connections (across multiple geographic locations) and set up a way to link them all together as a logical interface (I think it was called a gateway). I then pushed out that gateways IP to the server over DHCP. I guess routing tables would have also worked. I assume all of this is possible with just pf.

These days, I have removed this functionality from my router and moved it directly onto the server. I run the container haugene/transmission-openvpn which creates and maintains a VPN for transmission, but also has a proxy I can direct other containers to use. This has the benefit of keeping more of the prerequisites of these servers managed in the same docker compose file. It bakes in most of the popular public VPN configs, so you can enable them with a few ENV vars.

As a current pfSense user, I ask how troublesome this transition was? I run multiple vlans, snort, pFblockerNG, and wonder how difficult replication of these would be in OpenBSD, knowing that it's much more hardened, although FreeBSD/pfSense are supposedly faster...

I was a pfsense user for a few years up until last week. Before that I was an openwrt user.

I admit it was a bit nerve-wracking knowing that I'd be losing my Internet while the transition was in progress. In the end, it only took 5-10 mins to install OpenBSD itself and another hour or so to configure dhcpd, pf, unbound. Granted, I spent a few hours reading man pages and documentation before hand in preparation.

Wireguard took me a little bit longer but it's actually part of the kernel since OpenBSD 6.8 which is great. I don't think pfsense supports this yet in-kernel, but I could be wrong.

I have yet setup anything further than this except for automated borg backup to rsync.net.

In the end I'm extremely happy with my decision to move despite knowing that my apu2d4 won't achieve gigabit speeds pfsense on the same hardware is capable of. My Internet is only 200mbps so it's not an issue and if I upgrade I'll probably get a protectli.

While I feel the pfsense project is great, I simply feel more confident using command-line instead of web UIs and also knowing precisely how the system is setup without the pfsense magic.

Thank you very much for mentioning protectli out loud - that was all the clue I needed to look at their products, and wow. Their stuff looks absolutely fantastic.

If you’re willing to read documentation, OpenBSD is best-in-class for a secure, stable home router. The interfaces (configuration, CLI) are extremely simple and the man pages top notch.

I switched to OpenBSD on my desktop and remote server after many years of Linux use. It's now my goto OS for network connected stuff.

One caveat: A power cut during the relinking process that occurs during and after boot can wreck the filesystem. A UPS is advisable. Once the relinking finishes the filesystem is quite robust.