Messages

How about this approach:

• Gateway & Group management remains as-is
• Add a new page called "Gateway Priority" where one can add single gateways as well as gateway groups, and choose the order in which they're selected for use (i.e. the priority) in the same manner as one chooses the order of firewall rules (for UI consistency)
• The gateway selection algorithm walks over this new list (Gateway Priority) to select which gateway to use next upon a gateway failure/recovery. Groups already have priority internally, so when a group is found we either apply a "mini" version of the algorithm within the group's members (might me more elaborate), or simply "expand" the groups on the list in the proper order so it's just one big list of gateways (i.e. pre-process the list prior to running the selection algorithm, which might make it simpler)

Thoughts?

[exactly]

On that same note of backup/restore, I just had to do one b/c I swapped out the SSD that I had originally deployed on the firewall for a "real" (higher quality) one.

I noticed that the configuration file doesn't appear to contain information about the plugins installed, or the version. I realize why this is - so the configuration can be restored to an old(er) installation and still work, or be imported vertically to a newer one.

However, what I don't see anywhere is the means to actually run a "reproducible backup" where one can quickly, in "just a few clicks", restore the firewall to its prior state including all plugins, firewall version, packages, etc.

With this type of backup, the user would be able to restore a firewall to exactly the same state as it was before.  For example, at the start of the restore process the UI can ask if the user also wants to perform a roll-forward (or back, however the case may be) to the "installation state" (OPNSense version, packages, plugins) described by the configuration file (and, of course, show that state).

Does that make sense? Does that feature exist, and is it something that might be desirable?

I see it, and it should be about as simple as the

Code Select Expand

if (isset($gwsttng['disabled'])) check, except the setting name might be something like "non_wan_gateway".

Now I have to hunt down the UI page where the controls are, and add the new checkbox ;)

I might submit something by this Sunday.

Cheers!

I'm sure it's some little detail somewhere. I can send you a (sanitized) copy of my configuration, if that would help.

Cheers!

Enabling either (or both) setting(s) had no effect. Even rebooting once they were enabled. Any other thoughts?

Here you go... anything else I can provide you to help diagnose?

[dhcp-option DNS]

Hi!

I've configured an OpenVPN endpoint to be able to VPN into my home, but have hit a snag: it appears the OpenVPN configuration doesn't send the DNS server IPs that one configures over the wire for the client to consume. The domain setting has the same issue.

I had to manually add the push rules for dhcp-option DNS and dhcp-option DOMAIN to get it working.

Looking through /var/etc/openvpn I can see that the server configuration doesn't include those directives (unless I add them manually, of course).

I'll have a look at the plugin code to see if something jumps out at me as wholly amiss - maybe this can be my first contribution? :D

Cheers!

Sticky connections was already enabled, and per-interface gateway selection appears to only be possible for statically-configured interfaces (none of mine are - all are DHCP).

Any other ideas?

Final question: can you point me in the code to where the routing rotation is carried out? I'd like to see how much effort it'd be to add the "ignore this gateway when switching them" tidbit...

Is there any doc where the architecture/design of that area is described?

[and]

Interesting tidbit: if a gateway is marked as down, but monitoring is also turned off, it's still considered "up".

Shouldn't the "mark as down" option supersede the effects of "disable monitoring"? Perhaps I want to mark it as down and disable monitoring as well to save CPU cycles, but still always consider it down?

Perhaps a better UI choice is to have a 3-state selector condensing those two options where one can select whether a Gateway is "Always Up", "Always Down", or "Autodetect" (i.e. "monitor via ping")?

I think that'd be much more consistent and self-explanatory...

[BIG]

Being new, I don't mean to be bossy.  However, this seems like a truly BIG defect that shouldn't have gone neglected this long.

After looking at most of the issues, they're valid and definitely need fixing. And, of course, one can't neglect the fact that there are paying customers out there requiring these fixes.

However, this is the core routing not functioning as one would expect it to.  In short: multi-wan can't be considered robust unless the FW only has one non-public network behind it (ie. all configured gateways are WAN gateways).  If I have at least one non-WAN gateway that needs configuring for proper routing, the FW's behavior on a failover (and, worse-still, fail-back) scenario is inconfigurable, which makes it non-deterministic.

Needless to say, this is a VERY BAD THING ^(TM) for a firewall to (not?) do :)

So, I'll be happy to pitch in and lend a hand here if that's the main challenge. Not very well-versed on *BSD though. Not sure if OPNSense already does this, but perhaps manual management of the routing table (to apply configured priorities, allow gateways to be marked as non-WAN for ignoring, etc) is an option?

Again - don't mean to preach or be bossy. Just a little surprised something this key and this big doesn't even have a plan-of-attack for a solution yet.

I'll start poking around the code on my spare time in hopes of understanding how a solution might be implemented.

Cheers... and thanks for the rapid responses!!  All of this bitching aside, congratulations on a great product! I'm very impressed with all of it (except, obviously, the above) so far!

Hi!

I have a Multi-WAN setup, which after some toil (mostly due to my newbness :D ) appears to be (mostly) working the way I want it to (thanks to mimugmail for helping me out!). However, there's one thing not working right now that I can't see my way past.

The WANs are set up for a failover scenario: if the primary fails, the secondary takes over. This works well enough. The problem is that while everything is up (i.e. primary is up), I'm unable to ping the secondary interface from a remote location. Pinging the primary works just fine.  When the primary is down and the secondary is up, then I can ping the secondary (now primary due to the failover) just fine from that same location.

The issue, I believe, has to do with default gateways. I can only set up one default gateway. I had to enable gateway switching to get around other problems (discussed here, there's some more fun hijinks on that topic but I digress).


Using the Packet Capture utility I can see that the traffic does arrive fine to the firewall on the secondary while the primary is up.  The problem is that a response is never sent out. This is because the primary had to be set as the default gateway (see the above link) for gateway switching to work, so the O/S (apparently) doesn't know to give those packets special treatment and bounce them right back the network interface they came from.


I know OPNSense isn't Linux, but the way to solve this in Linuxland would be to have a routing rule (using ip route) specifying that packets originating from a given interface's address are to be routed using a special routing table (built for that interface) where the default gateway is that interface's.


I have no clue how to do that on OPNSense-land (*BSD-land)...


Can you guys help me out?

I'm interested in looking into this - where (what branch?) can I have a look in?

[which]

Yes, but how does OPNSense decide which gateway should be used instead of the one that just went down? In the end, I have no means to tell OPNSense which gateways lead (eventually?) to the internet, and which ones just lead deeper into my network.

So... thoughts? Is there an already-planned feature that would cover this use case?

Hi!

I found another thread asking this same question, and this appears to be an unresolved topic. However, it's worth asking again.

I have some special routing needs which necessitate the definition of gateways to handle the traffic. My problem is that the firewall won't select the correct gateway to the internet, and so it'll occasionally become isolated and won't be able to check for updates (for instance).

The rest of the traffic works and flows just fine, though.

There's only a checkbox to select a default gateway, but my problem is I have a multi-wan setup.

Is there a way to configure OPNSense and tell it, specifically, which gateways lead to the internet so that it can rotate through them in the event of circuit failure (i.e. failover)? Alternatively, is there a means to set a gateway group as the default gateway?

Thanks!