Yep! The only issue I’m seeing now is with connection tracking. @filippo_carletti said he was going to create an issue for it. Is there a way to reset connection tracking upon a lsm event?
I’m still not convinced that cutting connections by default is a good idea.
I’ll try to explain my point of view.
Imagine some ssh connection going through the firewall provider 1, which goes down for a brief time (less than 5 days actually): if we do not clear the conntrack table, my connections will probably remain up (and I usually have many open ssh connections).
If we use different stateless protocols (http) we will not have problems at all.
The only case I can imagine where you need to clear conntrack is when testing with ping.
Am I missing some scenarios?
In case, we could add a switch to enable/disable conntrack cleaning.
I see your point. Any stateful services/applications that are in use could be disconnected and reconnected after a few seconds and they would then reestablish over the other wan connection. Most applications will detect the connection dropped and disconnect or start a retry countdown…ssh doesn’t?
So maybe it’s not really an issue… I’ll see if I can do some testing with RDP and some common Jabber, FTP, and telnet clients. Any other common stateful applications I should test? I would assume if the standard retry periods of some of these common applications are greater than the timeout for connection tracking, everything should be fine.
Thanks to @Adam this feature has been released.
Just be a little patient for the documentation 
1 Like
I’m using the new implementation on some firewalls in production. So far I’m fairly satisfied with the update. 
I had to tune packet loss percentage to 50% on an unstable adsl line to avoid some false positives link status change.
Just to update… I did some testing and everything works perfectly!
3 Likes