Messages

What prevents you from using the business release in a business context?

Also the community releases are usually perfectly stable for any home deployment. If you have an issue, just report on Github.

hmmm may be same issue
https://forum.opnsense.org/index.php?topic=29757.0

once the wan link is down or for a long time it seems to be tagged as down indefinitely

It could be the same issue. Have you checked the routes?

so it seems 22.7 needs some work.  it's either a bsd issue, a middleware issue or a combination of the two.  This unfortunately means we will be leaving a brand new opnsense firewall at 22.1 forever...when and IF this issue gets fixed we might try going forward.  It's also strange that is generates a nearly 5 second outage going either way in 22.7 when it's nearly instant on 22.1.

If you're facing the gateway issue I described before, configuring static routes should serve as a workaround. If this isn't the issue you're facing, I didn't understand your problem. However, I guess the gateway issue will be resolved soon: https://github.com/opnsense/core/issues/5956. OPNsense is great and I have a lot of respect for the devs.

My method, although "feels dirty" does work

I guess it's fine as long as it works for you :D

What would happen if I didn't kill all the states in my script but instead just downed the WAN2 interface?

Could you see any issues with that?

I don't see any issues with that, it just seems to be the sledgehammer approach for just killing states. Downing an interface does a bit more if you look into interface_bring_down function in /usr/local/etc/inc/interfaces.inc (I suppose this is where the magic happens). To clear the states it runs /sbin/pfctl -i <interface> -Fs (so it seems to work with the interface parameter). But whatever works for you.

EDIT: I think it was WireGuard that kept its state on WAN2 using kmod

You mean traffic coming from wg clients kept being routed to the internet via WAN2?

Thanks for answering!

1) Well, that's interesting. Have you ticked "Allow default gateway switching"?

2) Ok, it seems to work for me. How did you try to kill them? I guess you can't use the interface with pfctl (haven't tried yet) as the states are floating by default (can be changed by "Bind states to interface").

I think there are different issues getting mixed up.

1.)
There seems to be an issue since 22.7 - at least for me - with the primary WAN gateway staying offline when the primary WAN interface is up again. The reason appears to be that the host route for the monitoring IP doesn't get added as soon as the interface is up again. I resolved this by adding the host routes for the monitoring IPs manually. This fixed the issue for me and the default route switches back to the gateway of the primary WAN link (with "Allow default gateway switching" ticked). Does this issue exist for you as well?

2.)

I just assumed OPNSense never did it, but did think it strange.

I guess what you are mentioning here is that the states are kept. With earlier releases of OPNsense it was possible to untick "Disable State Killing on Gateway Failure". However, this setting does not exist anymore. See here: https://forum.opnsense.org/index.php?topic=28179. I went the same route as you and wrote a script to handle this (and some other things) as soon as the default gateway switches. Aside from running this in a cron job, you can place it in /usr/local/etc/rc.syshook.d/monitor/ to be run on monitor events. See here: https://docs.opnsense.org/development/backend/autorun.html. I think you don't need to down the interface. I use pfctl -k <wan_ip> to kill the states (where wan_ip is the IP of WAN2 gateway after switching back to WAN1) and it works for me. Flushing all states seems not necessary.

I think the issue is that the route for the monitoring IP of the WAN link gets removed as soon as the link is down. Therefore the monitoring checks don't work anymore. At least this is the case when I disconnect my primary WAN link. Setting the routes manually seems to be a decent workaround. However, I agree that it looks like a bug. I did't find time yet to dig deeper into the issue and file an issue on Github.

How is your multi WAN setup configured? Do you just use gateway switching or employ the gateway groups? Keep in mind that switchting back from WAN2 to WAN1 does not force all existing connections to switch back. The pf states are kept.

I solved this with a Python script and a cron job to check if there was an IP change. On a change I edit a custom YAML config containing the vars and set the current WAN IPs as HOME_NET. After updating the config, the script restarts Suricata.

Hey guys,

since the option "Disable State Killing on Gateway Failure" is removed* since a while now, I was wondering how to get back the "old" behaviour without the option beeing ticked. I just use default gateway switching with my dual WAN setup and have a metered LTE connection as backup. As soon as my primary WAN comes back online I want all states to be killed, so that there is no traffic beeing routed via my backup link any longer.

Thanks!

EDIT: I wrote a script to handle this for now.

*https://forum.opnsense.org/index.php?topic=28179

I also ran into this issue. Try setting static routes for the monitored IPs via the corresponding gateway. This solved it for me.

Hello,

I have IPS enabled on the WAN interfaces of my OPNsense box. As I have my public IPs (with NAT) directly on the OPNsense, I must add the IPs to the Home networks field. This isn't a problem for my primary WAN link which has a static IP address. However, on my backup link the IP changes every now and then. Is there a way to edit the Home Networks dynamically via a script? It should be doable by editing the HOME_NET variable in the suricata.yaml, I guess. But is there a better way? I think the API does not provide access to the Home Networks setting, at least I do not know how.

Thanks!

I also noticed an increase in interrupts since the upgrade. Maybe this is related.

Yes, I noticed exactly the same on my box with Zenarmor active. I didn't see any temperature issues prior to the upgrade. On average, the temperature seems to be ok (no really higher than before) but there are many spikes up to 80 to 90 degrees Celsius.

Good to know that I wasn't the only one with this issue and good that you were able to resolve it as well :)

Just re-installing elasticsearch didn't help as the config file was still missing. Zenarmor also lost the database path. Very strange.

However, performing a backup within Zenarmor, uninstalling and re-installing it and then restoring the backup resolved the issue.

I'm still not sure which of the latest updates caused the issues.