Failover stucked on backup link
-
The monitor IP is 89.122.156.*** and is replying to ping queries. Changing the monitor ip to 8.8.8.8 didn´t helped. And yes, a google public dns is among those used:
Jul 4 02:01:13 dnsmasq[1013]: server 62.217.193.1#53: queries sent 748425, retried or failed 18588 Jul 4 02:01:13 dnsmasq[1013]: server 193.231.100.134#53: queries sent 737650, retried or failed 0 Jul 4 02:01:13 dnsmasq[1013]: server 193.231.100.130#53: queries sent 737652, retried or failed 1 Jul 4 02:01:13 dnsmasq[1013]: server 8.8.4.4#53: queries sent 737652, retried or failed 0 Jul 4 02:01:13 dnsmasq[1013]: queries forwarded 748428, queries answered locally 147664 Jul 4 02:01:13 dnsmasq[1013]: cache size 10000, 0/1348664 cache insertions re-used unexpired cache entries. Jul 4 02:01:13 dnsmasq[1013]: time 1278198073 -
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.
