diff options
author | Phil Davis <phil.davis@inf.org> | 2014-12-31 23:09:17 +0545 |
---|---|---|
committer | Renato Botelho <garga@FreeBSD.org> | 2015-01-05 11:17:27 -0200 |
commit | 62403377e171ae20d65fb33d4ffd1692a96ec4f2 (patch) | |
tree | b213d4ea65bc8160e13e3ad1b1be78b183b569c9 /etc/inc/gwlb.inc | |
parent | 5a158a29698405a1d3ee759dcbf9a95f9150e12e (diff) | |
download | pfsense-62403377e171ae20d65fb33d4ffd1692a96ec4f2.zip pfsense-62403377e171ae20d65fb33d4ffd1692a96ec4f2.tar.gz |
Do not monitor a gateway that has not got DHCP yet
When an interface is waiting to get DHCP, but the cable is physically-electrically connected to the upstream device, the interface has an IPv4 address 0.0.0.0 - that was getting past here and, if the interface gateway had a monitor IP specified, that monitor IP was being put into apinger.conf and being monitored. Because the interface has not got a gateway yet, no static route is added to force the traffic for the monitor IP out the particular interface. So the traffic to the monitor IP can follow the default route and perhaps succeed in getting out another WAN to the monitor IP.
The downstream results of this were:
1) Gateway status appears up and reports real RTT and Loss statistics, even though the interface is down.
2) Generation of rules for a gateway group that has this gateway as tier1 will think it is up, and thus try to policy-route traffic to it - which then does not get anywhere.
3) DynDNS status of a gateway group that has this gateway as tier1 shows the cached IP in red - it thinks the interface/gateway is up and tries to find the public IP by trying to get to checkip.dyndns.com through the interface/gateway. That of course fails.
4) I'm sure there are other things that depend on checking gateway and gateway group status that would also be getting it wrong in this condition, because apinger is being told to monitor, and manages to successfully monitor, an interface/gateway that has not yet got DHCP.
When waiting for DHCP, ifconfig shows like this on my system (WAN is on a cable to a VLAN switch):
vr0_vlan70: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:0d:b9:24:59:c0
inet6 fe80::20d:b9ff:fe24:59c0%vr0_vlan70 prefixlen 64 scopeid 0xf
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 70 vlanpcp: 0 parent interface: vr0
From what I can see, this little 2-line fix ends up correcting all the downstream effects I listed above.
Should fix RedMine #4094
Diffstat (limited to 'etc/inc/gwlb.inc')
-rw-r--r-- | etc/inc/gwlb.inc | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/etc/inc/gwlb.inc b/etc/inc/gwlb.inc index 15d8962..887faa9 100644 --- a/etc/inc/gwlb.inc +++ b/etc/inc/gwlb.inc @@ -180,6 +180,9 @@ EOD; if (!is_ipaddrv4($gwifip)) continue; //Skip this target + if ($gwifip == "0.0.0.0") + continue; //Skip this target - the gateway is still waiting for DHCP + /* * If the gateway is the same as the monitor we do not add a * route as this will break the routing table. |