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:
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.
Forgot to mention: frr. Should support fibs; I haven't used it.
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
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.
Quote from: AdSchellevis on November 26, 2025, 09:00:11 AMNot 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).
Quote from: bimbar on November 26, 2025, 12:05:38 PMI 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.
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.
Quote from: Fredouil on December 27, 2025, 11:44:41 AM[...]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.
Quote from: Fredouil on December 27, 2025, 11:44:41 AMprofessionals 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.
Multi-WAN stability would greatly improve if 'gateway groups' and WAN interfaces would be implemented on top of dedicated FIBs instead of policy routing.
Such setups are notoriously unstable because connections get bound to the wrong local IP address; this is because "monitoring IP host routes", default routes, static routes and dpinger all fight over the same FIB.
Btw., OPNsense 26.1 just broke Multi-WAN completely... maybe a good occasion to "rethink" this feature without the burden of a migration path.