Gateway monitoring still not OK
-
On the dashboard my IPV6-gateway is still shown as unkown (see pictures below).
Which is very strange IMHO, since under interfaces you can see that GW IPV4 and IPV6 addresses are known and can be pinged.
A simple ping would show if the GW does have IPV4 and/or IPV6 connection including the related ping times. SO I do not understand what makes it so hard to solve this problem !!
-
@louis2 said in Gateway monitoring still not OK:
On the dashboard my IPV6-gateway is still shown as unkown (see pictures below).
Which is very strange IMHO, since under interfaces you can see that GW IPV4 and IPV6 addresses are known and can be pinged.
That interface doesn't have a routeable IPv6 address or an upstream route for IPv6 traffic. The monitor display is consistent with that.
Pic below is for a WAN interface with IPv4 and IPv6 configured (the latter boxed in red).
Your gateway would only be pingable at its WAN v6 LLA from a device on that network segment (and probably not even then because of PPPoE ... can't test here).
-
You can ping a link local address from within the local lan no problem! And my IPV6 is working. See below.
I really do not understand the problem!
-
@louis2 said in Gateway monitoring still not OK:
problem!
If 2a02:a47f:e000::53 (ns1.ipv6.kpn.net) works = replies to ping, why not use it as a gateway test IPv6 ?
Edit the IPv6 "System > Routing > Gateways > Edit" and add
Save.
You should be fine now.That said, normally, you should have a 'real' rout-able IPv6 on your WAN interface :
-
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!
-
@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:
️ -
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.
-
@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).
️ -
@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.
-
@louis2 said in Gateway monitoring still not OK:
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 defaultshow 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.
-
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!
-
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 coreIf 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.
-
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? -
@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 coreYou 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.
️ -
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%pppoe0netstat entrys as related to nic igc and ppoe are:
::/0 fe80::9217:3fff:fe7f:e4a1%pppoe0 UG pppoe0
::1 link#4 UHS lo0fe80::%pppoe0/64 link#32 U pppoe0
fe80::2a0:c9ff:fe22:60aa%lo0 link#4 UHS lo0fe80::%igc0/64 link#1 U igc0
fe80::2a0:c9ff:fe22:60aa%lo0 link#4 UHS lo0fe80::%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 lo0fe80::%igc0.7/64 link#29 U igc0.7
fe80::2a0:c9ff:fe22:60aa%lo0 link#4 UHS lo0No 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
-
@louis2 said in Gateway monitoring still not OK:
::/0 fe80::9217:3fff:fe7f:e4a1%pppoe0 UG pppoe0
::1 link#4 UHS lo0Ok 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.
-
@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 -
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.
-
I will do that for the moment ..... but it is IMHO not the correct solution.
-
The fact your ISP doesn't respond to pings? Not much we can do about that!
