Failover stucked on backup link
-
Existing sessions won't bounce back to the DSL. If you're moving a lot of traffic to/from the same IPs, you may be stuck on the 3G for a while. Clearing out existing states should fix it.
-
Try configuring another new Failover pool and rules (make sure default Gw is tied to this new pool) it should work.
-
@jasonlitka: a while = a few hours ??
@mav2929: I don´t understand you suggestion. Are you saying that I should duplicate the existing pool? -
How do you test, that it doesn't fall back?
And yes, if you have a continuous stream (connection) on your backup WAN it wont fall back in a few hours. (it will never fall back) -
@jasonlitka: a while = a few hours ??
However long a connection/session is active.
It will not cut off an existing session just because the WAN came back online. (I think there might be an option to do just this in 2.0 in the works)
-
@jasonlitka: a while = a few hours ??
Indefinitely if there is a stream of data regular enough to keep the session alive. 1 ping per second, for example, is more than enough to do it.
-
How do you test, that it doesn't fall back?
tracert www.google.ro or any other site.
It will not cut off an existing session just because the WAN came back online. (I think there might be an option to do just this in 2.0 in the works)
This ˝feature˝ is nasty, since I have to pay for the 3G traffic…
-
Most people would prefer to keep their sessions alive rather than abruptly cut off users, but with metered links that is a valid issue. A preference for it would be idea.
http://redmine.pfsense.org/issues/8
-
How do you test, that it doesn't fall back?
tracert www.google.ro or any other site.
It will not cut off an existing session just because the WAN came back online. (I think there might be an option to do just this in 2.0 in the works)
This ˝feature˝ is nasty, since I have to pay for the 3G traffic…
If you can pick a random site where you know your users haven't been visiting and you're still seeing traffic going out the 3G card when the main link is back up then something is wrong. It is only sticky for existing connections.
-
Nope, same issue. But I found a workaround: using opt1 and opt2 interfaces in the failover pool.
