New PPPoE backend, some feedback

[stephenw10]

I don't think that's if_pppoe dircetly, it has no awareness of IPv6. It's somehow one of the other changes that were added to allow both pppoe types to function.

But you don't see it with if_pppoe disabled? So it must be something that's only triggered when it is.

[RobbieTT]

@stephenw10
Surely it still handles the IPv6 setup and configuration during the PPPoE session initialisation, including any subsequent changes from upstream... or am I mistaken?

️

[stephenw10]

Nope all that is dhcpc6 once the pppoe is up. It's an odd situation because pppoe does have scope to setup IPv6 like does for v4 (IP6CP) but I have never seen it used. By anything.

For reference: https://www.revk.uk/2011/01/ppp-ipv6cp-vs-dhcpv6.html
And that's straight from RevK so you know it must be true. Or was in 2011!

[benbng]

I'm unable to route traffic via an IPv6 gateway on 2.8.0 as I am having the same problem as highlighted by @louis2 where my gateway is pending:

I have tried restarting dpinger, disabling/reenabling the gateway and unchecking Do not wait for a RA however these actions have had no effect.

Here are my interface settings using if_pppoe (I have noticed the Host-Uniq value I have set is not visible here but my ISP doesn't require it):

Interestingly I have noticed when viewing the Interface that it does not show the Gateway IPv6 value like is visible for mpd:

There is however a default route set and the gateway address is pingable:

Internet6:
Destination                       Gateway                       Flags   Nhop#    Mtu            Netif Expire
::/0                              fe80::1239:e9ff:feb2:1744%pppoe1 UG      39   1500           pppoe1

PING(56=40+8+8 bytes) fe80::4262:31ff:fe0b:8156%pppoe1 --> fe80::1239:e9ff:feb2:1744%pppoe1
16 bytes from fe80::1239:e9ff:feb2:1744%pppoe1, icmp_seq=0 hlim=64 time=3.586 ms
16 bytes from fe80::1239:e9ff:feb2:1744%pppoe1, icmp_seq=1 hlim=64 time=3.215 ms
16 bytes from fe80::1239:e9ff:feb2:1744%pppoe1, icmp_seq=2 hlim=64 time=3.365 ms

--- fe80::1239:e9ff:feb2:1744%pppoe1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.215/3.389/3.586/0.152 ms

When using mpd implementation for contrast (interface settings are identical):

I have seen the following event appear in the logs a few times but unsure if this is of any help: if_pppoe: pppoe1: failed to set default route 17

[stephenw10]

Hmm so you only see that when using if_pppoe? And IPv4 works fine in both cases?

Probably going to need to compare the system and dhcp logs to see what the difference is there.

[louis2]

@stephenw10

Hum .. I had to think about the rout-able IPV6 in the picture higher up, so I looked at my PPOE overview.

As you can see in my case there is an link local address, which does not surprise me. And I checked it is pingable

not from some other lan of course!! It is a link local address

[Bob.Dig]

@benbng I wonder, why you have a MTU of 1500 with PPPoE, usually it is lower.

[louis2]

@benbng

I wonder does the IPV6 address in your TROOLI interface to your IPV6 range or is it an address in the providers infrastructure at the providers side of the PPOE !??

[benbng]

@stephenw10 logs below as requested.

mpd
mpdsystem.txt
mpddhcp6c.txt

if_pppoe with Do not wait for a RA checked
ifpppoesystem.txt
ifpppoedhcp6c.txt

if_pppoe with Do not wait for a RA unchecked
ifpppoesystemnora.txt
ifpppoedhcp6cnora.txt

I can confirm IPv4 connectivity is working from clients using both mpd and if_pppoe. When using if_pppoe the firewall itself has IPv6 connectivity (with addresses outside of my ISP's network) however any internal client traffic that matches a firewall rule with the IPv6 gateway is not routed, certainly looks like something to do with pfSense gateways as opposed to a routing/PPP/DHCP issue.

Let me know if I can provide any additional logs.

[benbng]

@Bob-Dig there was some talk about this towards the start of the thread; a number of ISPs within the UK support https://datatracker.ietf.org/doc/html/rfc4638 which accounts for the PPPoE overhead and enables devices to use an MTU of 1500 without having to resort to MSS clamping or any of that fun.

[benbng]

@louis2 sorry which address are you referring to? The IPv6 Address is on the provider's side and allocated from the DHCPv6 request, the Gateway 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 to receive advertise from fe80::a:b:c:d%pppoex)

[louis2]

@benbng

That is what I did expect, but wanted to know for sure.
Thanx

[stephenw10]

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

[benbng]

@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?

[stephenw10]

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.

[louis2]

@stephenw10

?? What is wrong about that ?? And why is my IPV6 gateway still showing as unkown, where it is working perfectly ??

[stephenw10]

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.

[benbng]

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.

[stephenw10]

Hmm, good catch. Do you see the policy routing rules in the ruleset? (/tmp/rules.debug) Do they have the gateway on them?

[benbng]

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