VRF support

[FlangeMonkey]

Hi Guys,

Is there any support for VRF's?  I have a use case for a Management/OOB interface.

Thanks,

[lilsense]

check out FRR plugin to see if that's supported. The BGP is fully supported so I presume so is VRF.

[franco]

FreeBSD can support multiple route tables but does not compile it by default. Such options are rarely production ready or have little support so we never supported it and likely will so in the future. However, vimage(8) is in the kernel since 20.7 and that would enable running multiple virtual network stacks, but how that could be integrated into OPNsense in a sensible way is above my pay grade currently.  ;)


Cheers,
Franco

[FlangeMonkey]

Thanks for your replies guys.  I am currently running FRR but I don't see anything in there for routing instances, VRF, etc.  I could maybe do it manually in FRR's configuration, but I'm unsure if that would be persistent.

I'll check out the kernel requirements such as the mentioned vimage, so thanks for that.  If it's fully enabled on the kernel in 21.7, I'll play around with it.

I have implemented policy-based rules to get this working ATM, but multiple tables would be preferable.

Thanks,

[bimbar]

VRF is not necessarily BGP related. What you want is probably a VRF-Lite functionality. This is a quite unusual feature for firewalls, perhaps you'd be better off pairing a router with your firewall for that.

[lilsense]

not necessarily... with a VRF interfaces you can create a Virtual Firewall for that particular VRF or VRFs...

[marin]

FreeBSD can support multiple route tables but does not compile it by default. Such options are rarely production ready or have little support so we never supported it and likely will so in the future.

In fact, since FreeBSD 12, the GENERIC kernel ships with support for 2 routing tables. There is no need to build a custom kernel anymore, unless one needs to use more than 2 FIBs.

We use this feature extensively on our routers, as it allows to split administration and clustering interfaces (those running SSH, pfSync, config sync, HAProxy sync, etc.) from interfaces dedicated to production workloads. Administration interfaces are implicitly assigned to default FIB 0, while other ones are explicitly assigned to FIB 1.

This setup is fairly easy to configure. Just add:

Code: [Select]

net.fibs="2"
to /boot/loader.conf.local to make the kernel initialize 2 routing tables at boot time.  Then add:

Code: [Select]

net.add_addr_allfibs="0"
to /etc/sysctl.conf to prevent the kernel from binding all interface addresses to all FIBs (which it does by default, but this might change in a future release).

After a reboot, the kernel should be able to handle 2 distinct VRFs. I did not test these changes on OPNsense, but AFAIK they should not introduce any feature regression as both the kernel and userland are expected to use FIB 0 by default, just like in a standard setup.

From then, one may assign an interface to another FIB with the fib keyword. For instance, to bind interface vtnet2 to FIB 1:

Code: [Select]

ifconfig vtnet2 fib 1
Unless the fib keyword is specified, the interface will remain on FIB 0.

Routing works the same way. Most route actions support a -fib option to specify the target routing table. For instance:

Code: [Select]

route add default 192.168.1.254 -fib 1
Would add a default route on the second routing table (FIB 1).

The use of several routing tables does not seem to affect pf operations that much. By default, pf will process packets regardless of their FIB, and won't allow them to cross FIB boundaries. The rtable keyword may allow cross-FIB routing, but I never tested it. While the OpenBSD pf supports filtering packets by VRF (via the rdomain keyword), this is not possible on FreeBSD. I also noted that using several FIBs seems to break pf URPF checks.

The use of several routing tables allows us to maintain cleaner/safer rule sets on our BSD firewalls. It is also the only way to avoid asymmetrical routing in scenarios where the administration interface of the firewall must communicate with production networks via an external path. Adding support for multi FIBs would make OPNsense usable in such contexts.