Gateway monitoring still not OK

louis2

OK I notice there is a work around. However IMHO it is still nonsense !!

A gateway is a local end point. I do not see any reason why it should have a (internet) rout-able address!! More over mine does not have any and it is working perfectly!

So why the software is not just using that link local address ?????, I just do not understand!

RobbieTT

@louis2

@marcg is correct and worth reading again.

As you noted, pinging something on the wider internet isn't really the point (although some do this knowingly, using what is a 'gateway' test function as a wider internet connectivity test).

Regarding routable end points remember that in IPv6 land the goal was to make everything globally routable.

The pfSense feature to monitor the gateway relies on information provided by the ISP during the initial handshake. If it is missing elements or there is a misconfiguration somewhere it may not work as desired.

Mine:

2025-07-14 at 12.39.20.png

️

louis2

@RobbieTT

No, I do not agree. There is no need for an routable IP-address here. The GW is accessable from the lan and that is more than enough.

And the goal of IPV6 is not to give every thing a routable address. I can imagine lots situations where you do not want things to be globally accessible.

RobbieTT

@louis2 said in Gateway monitoring still not OK:

@RobbieTT
And the goal of IPV6 is not to give every thing a routable address. I can imagine lots situations where you do not want things to be globally accessible.

It was, whatever your feelings about the wisdom of it. You may need to hold on to your hat for the next one then... back in the day this was also true of IPv4; way before NAT had to come to the rescue.

External accessibility is controlled by firewalls, not the IP protocol (or NAT).

️

stephenw10

@louis2 said in Gateway monitoring still not OK:

The GW is accessable from the lan and that is more than enough.

A link-local WAN gateway absolutely should not be accessible from the LAN. It would only be accessible from the same layer 2 segment which would be the WAN side here.

Looking at your tests it looks like you're pinging something local though. There's no way you'd see a response in 0.05ms over a pppoe link! In fact that looks like you're pinging the same address as the source.

0.3ms on the IPv4 gateway also seems unlikely but possible.

But yes, you're right, you don't need a routable IP on the WAN. You should still see a LL gateway from the ISP and that's (usually) pingable.

marcg

@louis2 said in Gateway monitoring still not OK:

@marcg

And my IPV6 is working. See below.

That's a KPN nameserver. Is KPN your ISP and, if so, can you ping hosts upstream of their network like Google DNS, 2001:4860:4860::8888 ?

Also, does netstat -rn | grep default show a default v6 gateway?

I've seen odd v6 gateway monitor results in the past, where the default gateway wasn't listed even though v6 was up and a default route was shown by netstat.

louis2

@marcg

Yep KPN is my provider and of course I could ping the name server or the ^white house^ to check if there is connectivity.

However IMHO, that is not relevant. I just want to know if the providers network is reachable!

louis2

@stephenw10

Stephen, I just do not understand this, however perhaps I am mistaken.

The only thing I would like to know, is if I can access the providers network, and the reaction time of the providers network. Nothing more and also nothing else (not the reaction time of the dns server or something else) !!

So the PPOE-interface as running on pfSense has two connections:

one to the providers equipment
one to the firewall core.

If I look at the interface status page it become confusing. In the row IPV4-address

for all interfaces the lan address towards the firewall core
and perhaps that is also true for the WAN, you see there the external IP address. And there it becomes hazy

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

If that is true than the IPV4 address shown is the address at the "A" side / provider side of the PPOE-client.

And if that is true than is also the ^IPv6 Link Local^ in the status overview an address at the provider side of the PPOE-interface.

And as a consequence of this testing the connection towards the provider using addresses in the interface overview (IPV4 and IPV6 link local) is probably valid and correct !!!!

Still some doubts give by lack of knowledge related to PPOE !! And its true what is the address at the provides side <> the address on the PPOE input side.

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..