Gateway monitoring still not OK

stephenw10

The interface IPv6 address should be your local Link-local address. The gateway IPv6 address should be the ISPs link-local address.

Neither of those should be pingable from a client on another internal interface.

For some reason your interfaces status page doesn't show an IPv6 gateway but you are able to ping external IPv6 addresses.

So you must have an IPv6 gateway. What does it show as in netstat -rn?

RobbieTT

@louis2 said in Gateway monitoring still not OK:

@stephenw10
I assume that the way it works is like this
provider =>(A) => PPOE-client =>(B) => firewall core

You are close. Your firewall (pfSense) talks via the 'WAN' side interface to the upstream gateway (ISP-side) via the link-local addresses. At the start these are the only known addresses.

From there they both negotiate a PPPoE session and the ISP provides all the relevant details the firewall needs (including IPs, IPv6 blocks, router advertisements, encryption etc). Once all this is negotiated the actual firewall WAN connection now has a clear routable path through the upstream gateway (via the PPPoE tunnel) to the wider internet and back again. In this way the 'gateway' is typically the 'first-hop' from your firewall/router.

[Occasionally people may have a vendor-provided box between the firewall and the gateway either in bypass mode or the dreaded double NAT. Clearly this is less desirable and usually avoided.]

Anyway, a somewhat simplistic description but it avoids the rabbit holes.

️

louis2

@stephenw10

The trunk towards my provider is connected via nic igc

there are three vlan's 4,6 and 7 and next to that ^default vlan0^

The pfsense interface screen shows:
IPv6 Link Local fe80::2a0:c9ff:fe22:60aa%pppoe0

netstat entrys as related to nic igc and ppoe are:

::/0 fe80::9217:3fff:fe7f:e4a1%pppoe0 UG pppoe0
::1 link#4 UHS lo0

fe80::%pppoe0/64 link#32 U pppoe0
fe80::2a0:c9ff:fe22:60aa%lo0 link#4 UHS lo0

fe80::%igc0/64 link#1 U igc0
fe80::2a0:c9ff:fe22:60aa%lo0 link#4 UHS lo0

fe80::%igc0.6/64 link#23 U igc0.6
fe80::2a0:c9ff:fe22:60aa%lo0 link#4 UHS lo0
fe80::%igc0.4/64 link#28 U igc0.4
fe80::2a0:c9ff:fe22:60aa%lo0 link#4 UHS lo0

fe80::%igc0.7/64 link#29 U igc0.7
fe80::2a0:c9ff:fe22:60aa%lo0 link#4 UHS lo0

No IPV4 addresses in the list.

Not that it matters but the situation is as follows:

ISP fiber switch
some small frontend switch (mine)
pfSense NIC igc

stephenw10

@louis2 said in Gateway monitoring still not OK:

::/0 fe80::9217:3fff:fe7f:e4a1%pppoe0 UG pppoe0
::1 link#4 UHS lo0

Ok so you have a default route via the ISP gateway. dpinger should be seeing that and trying to ping it.

Does that respond to ping from pfSense? With a reasonable response time?

Check the logs for when that route is added.

louis2

@stephenw10 said in Gateway monitoring still not OK:

fe80::9217:3fff:fe7f:e4a1%pppoe0

Further on I did disable the WAN, cleared the log and enabled the WAN again.

From the log

Jul 15 08:09:11 pfSense php-fpm[79878]: /interfaces.php: Resyncing OpenVPN instances for interface WAN.
Jul 15 08:09:11 pfSense php-fpm[48595]: /rc.newwanip: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6'
Jul 15 08:09:11 pfSense php-fpm[48595]: /rc.newwanip: Gateway, NONE AVAILABLE
Jul 15 08:09:08 pfSense check_reload_status[701]: updating dyndns wan
Jul 15 08:09:07 pfSense check_reload_status[701]: Restarting IPsec tunnels
Jul 15 08:09:07 pfSense php-fpm[79878]: /interfaces.php: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6'
Jul 15 08:09:07 pfSense php-fpm[79878]: /interfaces.php: Gateway, none 'available' for inet, use the first one configured. 'WAN_PPPOE'
Jul 15 08:09:07 pfSense php-fpm[79878]: /interfaces.php: calling interface_dhcpv6_configure.
Jul 15 08:09:05 pfSense check_reload_status[701]: Syncing firewall

stephenw10

Ok so the gateway doesn't respond to pings. Assuming that's still the same gateway.

So set an external IP to use for monitoring.

Though I would still expect to have seen dpinger try to ping and show loss rather than pending.

louis2

@stephenw10

I will do that for the moment ..... but it is IMHO not the correct solution.

stephenw10

The fact your ISP doesn't respond to pings? Not much we can do about that!

louis2

@stephenw10

If I add some address as gateway monitor address, I can not ping that address any longer (I can imagine ..)

And the gateway status in the GUI is not(!) changing

dennypage

@stephenw10 said in Gateway monitoring still not OK:

I would still expect to have seen dpinger try to ping and show loss rather than pending.

/etc/inc/gwlb.inc:

// dpinger returns '<gwname> 0 0 0' when queried directly after it starts.
// while a latency of 0 and a loss of 0 would be perfect, in a real world it doesnt happen.
// or does it, anyone? if so we must 'detect' the initialization period differently..