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.

[Fredouil]

Hello, I disagree with this analysis. I've lost count of the number of discussions where professionals say that if OPNsense supported VRF, they would immediately switch to that solution. I know many professionals who are reluctantly forced to turn to Fortinet, VYOS, or others because they have VRF or VDOM. I truly believe it would be a huge mistake to think this feature isn't important; it should be a priority. I'm giving you my analysis as an expert and professional who regularly meets with other professionals at trade shows.

[pfry]

[...]it should be a priority[...]

Heh. Whose confirmation bias is justified? (Does that matter?)

I'd implement it, as I come from a routing background. (Note that I started with firewalls at the same time.) I'm a lousy persuader; money talks, but I don't have enough for this one.

[Seimus]

professionals say that if OPNsense supported VRF, they would immediately switch to that solution

I agree that having VRF on OPN would be great, VRF or Instances depending on the vendor are widely used on FWs as well. There is a use case for them, and a reason its needed.

But this where "they would immediately switch" "if <PRODUCT> had <this>" is just bollocks. This is the same as listening to a Windows user telling they will switch to Linux if Linux has this or that.

Regards,
S.