New PPPoE backend, some feedback
-
@louis2 sorry which address are you referring to? The
IPv6 Address
is on the provider's side and allocated from the DHCPv6 request, theGateway IPv6
address is the ISP's router's link-local address which you can find when looking at your dhcp6c logs (for an entry similar toreceive advertise from fe80::a:b:c:d%pppoex
) -
That is what I did expect, but wanted to know for sure.
Thanx -
@benbng said in New PPPoE backend, some feedback:
any internal client traffic that matches a firewall rule with the IPv6 gateway is not routed,
That is the expected behaviour if the gateway is marked as offline. I assume that's not the default IPv6 gateway? If it is I'd expect anything passed without a gateway set to still be able to use it.
-
@stephenw10 it should be the default, because it's marked as pending though it doesn't show this as you can see in my earlier screenshots.
Interestingly the gateway doesn't seem to get populated as the monitor IP; is this supposed to be set within one of the scripts that has been changed as part of the 2.8.0 release?
-
If the gateway is off line any policy routing rules will either by applied without a gateway or omitted entirely depending on the Advanced Firewall Rule setting.
Any client IPv6 traffic that is passed without a gateway set should just follow the default route in which case it should work.
But that's not really the issue here, it's that dpinger ever starts on the link-local gateway for some reason.
-
?? What is wrong about that ?? And why is my IPV6 gateway still showing as unkown, where it is working perfectly ??
-
Unclear at this point. There certainly seems to be some combination of variables that prevents dpinger starting with a link-local gateway. I'm not sure what that is yet because it works fine on my own WAN and everything I've tested.
-
I noticed that when using if_pppoe the file containing the gateway address at location /tmp/pppoe1_routerv6 was missing; this file is supposed to be created by the rtsold script within /var/etc (and then used by function
get_interface_gateway_v6
.)I manually created this file (taking the gateway address from the default route) and then under Diagnostics > Command Prompt ran PHP Command:
setup_gateways_monitor();
after this my IPv6 gateway shows as Online, however despite the fact it is the default gateway for IPv6 it is still not forwarding traffic. -
Hmm, good catch. Do you see the policy routing rules in the ruleset? (/tmp/rules.debug) Do they have the gateway on them?
-
Ah thanks for that, I did a filter reload (via Status > Filter Reload) and it's routing now!
Something I have noticed is my ISP doesn't seem to be sending a Router Advertisement:
Could the rtsold behaviour be different when using if_pppoe in this situation? This is quite old but I wonder if it could potentially be related? https://redmine.pfsense.org/issues/14072
-
Hmm, it could. The RA behaviour of different ISPs seems to vary significantly.
Mine sends an RA each time the pppoe link connects. And only then. Which makes everything work just fine!
-
@stephenw10 said in New PPPoE backend, some feedback:
Hmm, it could. The RA behaviour of different ISPs seems to vary significantly.
Mine sends an RA each time the pppoe link connects. And only then. Which makes everything work just fine!
Is that an actual RA or solicited?
The variance of ISPs is probably the point and perhaps requires more care with if_pppoe. As it is:
2025-06-09 20:09:04.501728+01:00 php 57356 /usr/local/sbin/ppp-ipv6: Starting rtsold process on wan(pppoe0) 2025-06-09 20:09:04.501539+01:00 php 57356 /usr/local/sbin/ppp-ipv6: Starting DHCP6 client for interfaces pppoe0 2025-06-09 20:09:04.469732+01:00 php 57356 /usr/local/sbin/ppp-ipv6: Accept router advertisements on interface pppoe0 2025-06-09 20:09:04.046407+01:00 kernel - pppoe0: link state changed to UP
As soon as the pppoe link is up if_pppoe is always set to accept RAs and then (with not wait for RAs set) is directed to start the rtsold process. Perhaps asking the system to respond to both even with 'do not wait' set is asking for trouble?
️
-
It could be since I only see it after the parent pppoe connects:
Jun 8 06:45:47 rtsold 82638 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) Jun 8 06:27:57 rtsold 13619 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) May 28 16:24:04 rtsold 99252 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) May 28 15:30:10 rtsold 87300 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) May 26 05:02:01 rtsold 64029 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) May 18 17:11:41 rtsold 50394 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) May 16 19:31:17 rtsold 53108 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) May 14 04:24:39 rtsold 49956 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) May 10 20:01:04 rtsold 60529 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) May 6 20:36:28 rtsold 99065 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) Apr 30 15:01:59 rtsold 55432 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) Apr 30 14:34:11 rtsold 12977 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) Apr 30 14:03:08 rtsold 20686 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1) Apr 28 14:09:46 rtsold 73063 Received RA specifying route fe80::2621:24ff:fed9:623f for interface opt4(pppoe1)
I don't see anything logged either way but I wouldn't expect to.
-
Looking through my logs I see no events from rtsold as you do and having reviewed the rtsold man page I strongly suspect that in my case the supplement script will never run since an RA doesn't appear to be sent from my ISP.
I have noticed within /var/etc/mpd_opt10.conf the following line:
set iface up-script /usr/local/sbin/ppp-linkup
and within this script I can see:echo "${REMOTE_IP}" > "/tmp/${IF}_routerv6"
I'm guessing this could be missing for if_pppoe? -
if_pppoe uses pppoe-handler instead of those scripts:
https://github.com/pfsense/pfsense/blob/master/src/usr/local/sbin/pppoe-handler#L50 -
Can you see a tunnel6 value when you execute the following PHP command:
print_r(get_interface_addresses("pppoe1"));
?I cannot:
Array ( [status] => up [multicast] => 1 [pointtopoint] => 1 [simplex] => 1 [iftype] => other [mtu] => 1500 [caps] => Array ( [flags] => 0 ) [encaps] => Array ( [flags] => 0 ) [ipaddr] => 98.96.169.137 [subnetbits] => 32 [subnet] => 255.255.255.255 [tunnel] => 199.15.239.1 [ipaddr6] => 2001:db8:abcd:0012::1 [subnetbits6] => 128 )
-
I do, yes:
Array ( [status] => up [multicast] => 1 [pointtopoint] => 1 [simplex] => 1 [linkstateup] => 1 [iftype] => other [mtu] => 1500 [caps] => Array ( [flags] => 0 ) [encaps] => Array ( [flags] => 0 ) [ipaddr] => 86.191.x.x [subnetbits] => 32 [subnet] => 255.255.255.255 [tunnel] => 172.16.13.252 )
No IPv6 value because it's PD only.
-
I can't see
tunnel6
in the output you shared, I guess that won't be an issue for you since the rtsold script is creating /tmp/if_routerv6 but in my case since the rtsold script isn't firing the only way would be if that value is returned as per: https://github.com/pfsense/pfsense/blob/master/src/usr/local/sbin/pppoe-handler#L51So is this a bug when using ISPs that don't send an RA using if_pppoe?
-
It could be. There's certainly significant variation between ISPs RA handling.
-
Stephen, I wonder if it is perhaps a good idea to create a special version of the pppoe module which generates some debug logging's.
If you make that available as a patch I would more than happy to (temporarely) install and test it.