Killing states on the 3G backup link when the primary link comes back online ?
-
Is it now possible in a multi-WAN setup to have pfsense kill states on the lower-Tier "backup" (typically 3G, sometimes even ISDN dialup) connection when the higher-Tier primary connection comes back online ?
I was reading the 2-years old discussion at http://redmine.pfsense.org/issues/8 and wonder if this feature (quite handy, if one is using metered and relatively slow 3G link as backup) has been implemented since.
I implemented this feature on Linux some years ago, I didn't want to just kill all states immediately as soon as the primary link came back (as it would break all SIP phone calls), but I also didn't want to keep routing VoIP traffic over the slower backup link longer than I had to. So I had a cron job do the forced switch from backup to primary at a specific time at night (3:00am) which would presumably have minimal VoIP traffic.
Edit: And here http://forum.pfsense.org/index.php/topic,26430.0.html is the related discussion in the forum 2yr ago.
-
We don't yet have a hook in place for that, AFAIK.
Probably could be done in rc.newwanip somehow, the same or similar as is done for the new IPsec/OpenVPN/DynDNS failover.
The problem is it would have to be a master option somewhere with a specified gateway group set for it to act on. The reason for that is most people have multiple gateway groups, things like:
preferWAN1
preferWAN2
…So if you kill the states on WAN2 when WAN1 comes back up for the first gateway group, the connections on preferWAN2 would be unnecessarily cut off. There is no way around that, but requiring the user to set the option and a gateway group to control it gives an opportunity to let the user know the consequences of enabling that option.
Not sure if that could be done in 2.1 yet, we're trying to freeze the features as they are, squish the remaining bugs and get it out, then start on 2.2.
However, if someone coded it up and the code appeared as a pull request on github, it might be hard to pass up.
Jim
-
If the code analysed each state, looking at the source/destination parameters of the flow, it could then look at the firewall rules and decide which gateway group that flow would be put into if it was being created newly now. If it would go in a gateway group, then look at that gateway group's current state and determine which gateway(s) the flow would now be allocated to by the rules (potentially one of many equal Tier gateways in a group).
If the flow is not on one of the currently calculated gateway(s), then terminate it.
Obviously, provide "enable" checkboxes in various well-designed places for admins to enable this behaviour for changes in state of particular gateway groups, or for the whole system, and some time-delay or time-settings so that admins can specify how long to wait, what time of day… after a gateway group state change before blasting the remaining "out-of-date-routed" flows.
To do it flexibly and well might be quite a challenge. -
I doubt that would ever be feasible. It's too much work and in some cases, impossible to determine. If you have a large state table, it would take far, far too many resources for very little benefit.
