FIB/VRF support in OPNsense

[pfry]

There have been a few discussions of this in the fora; I didn't see any relevant github requests.

Would anyone be up for FIB/VRF support?

It could be implemented pretty simply. As with many OPNsense features, you could use VRFs/FIBs to really screw yourself up. But I think the feature would be quite usable. The beauty is that default behavior would not change in any meaningful sense, and it could be tested to a considerable extent without (GUI) implementation.

Details:

Possible kernel compile option: "options ROUTETABLES=n". Apparently the standard kernel can be configured (using "net.fibs", as below) for at least n=2. Appropriate setting? I imagine it would depend on impact, if any.

System:

• Settings:
• "net.fibs" in loader.conf. Not sure where to put this setting (General -> Networking, as "FIBs" or "VRFs"?). It would be used as an interlock for most of the settings below. Interlock behavior options: vanish/gray/do nothing/error on setting; zero/ignore fib settings when "net.fibs" is unconfigured.
• "net.add_addr_allfibs" - I would make this a tuneable, default 0. I'm not sure if this setting is still available, or if it will be in future versions.
• Gateways:
• Configuration:
• "fib" setting for the gateway.
• "fib" column (not selected by default) for the display. I would display data from all fibs, using "setfib n [command]", as n=0 should always be valid.
• Routes:
• Configuration:
• "fib" setting for the route.
• "fib" column for the display, as above.
• Status:
• "fib" column for the display, as above.

Interfaces:

• [Interface]:
• "fib": integer

Firewall:

• Automation:
• Filter:
• "fib" column for the display, as above. I would include this as the current display has lots of options.
• Rules:
• [Interface]:
• Interlock: for "Action" = Pass, "Direction" = In: "fib" (pf "rtable") setting: integer.

I've likely missed (quite) a few... e.g. "fib" for ping, trace.

Possible caveat: "route" may be fussy with fib > 0 - it might require an "up" interface in the fib in order to add routes. I'm not sure if this is a non-default behavior, as I haven't tested it.

[pfry]

Forgot to mention: frr. Should support fibs; I haven't used it.

[AdSchellevis]

Not at all easy to integrate (lots of moving parts), FRR by my knowledge doesn't support fibs either (e.g. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229136), only bird does as far as I know.

Best regards,

Ad

[bimbar]

I also think that VRFs are not that useful in firewalls - in routers, yes, but firewalls are supposed to connect different routing contexts, not to separate them.

[pfry]

Not at all easy to integrate (lots of moving parts)[...]

In context I wouldn't consider it particularly difficult, but it's not basic. Identifying all of the affected elements would be a pain, especially if they're not well encapsulated (as nobody does that).

I also think that VRFs are not that useful in firewalls[...]

I'd disagree there. But I will grant that it's a bit of a niche feature, and not popular with the OPNsense base. Part of the reason for that is that for most scenarios rule-based forwarding would work about as well; another part is the chicken/egg problem, but that merely partially contextualizes the lack of demand. From a cost-benefit value standpoint it looks pretty dead.