Gateway monitoring still not OK
-
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!
-
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
-
@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..
