IPv6 connectivity from LAN is lost after PPPoE reconnect
-
Thanks for the replies!
I've seen a loss of IPv6 connectivity not only with the "home user plan" with a changing WAN prefix but also with the "business plan" with a static WAN prefix. Both with the same provider (Telekom).
I just checked the "Do not allow PD/Adress release" option for both pfSense boxes and will report if this has fixed the issue.
The clients get their addresses either via SLAAC/unmanaged or DHCPv6/managed, depending on the VLAN. Normally it takes one day for the clients on the changing prefix plan to lose the connection (the prefix has changed then, too). With the static prefix plan, it takes a week or two and the prefix remains the same, of course.
@HG Thanks for your in-depth answer. I will try your method as soon as the clients lose IPv6 connection again. I suspect that this will be the case tomorrow.
-
@j-koopmann said in IPv6 connectivity from LAN is lost after PPPoE reconnect:
It has not happened to me for weeks now (so it is very hard do debug and @JKnott hence not easy to take a packet capture).
It would be hard with the pfSense Packet Capture, but not with a managed switch and Wireshark. I configured a 5 port switch as a data tap and leave a computer running Wireshark up for as long as it takes.
-
@HG said in IPv6 connectivity from LAN is lost after PPPoE reconnect:
You can e.g. check the IP addresses incl. the lifetime information on Windows with "netsh interface ipv6 show addresses". In this situation it shows 2 preferred public and 2 preferred temporary IPv6 addresses, the the old and with the new prefix. When you notice the problem the next time, go to a client that has this problem and explicitly specify the correct (new) source address (on Windows -S) when trying to ping something on the Internet. I expect that this will work.
I haven't found a setting that avoids this problem. The only workaround I found to far is to decrease the "Default preferred lifetime" so the client deprecate the address faster. But ideally radvd would just deprecate the old prefix (i.e. announce it with preferred lifetime 0). I never do a manual disconnect/reconnect (and I don't want to reconnect now to try it out ;) ), but @j-koopmann says that it doesn't happen then, so I assume that radvd does exactly that in this situation. Maybe @mphilippi you can check this when you are currently experimenting anyway.
As expected, the link with the dynamic prefix does not work with IPv6 anymore.
The WAN prefix changed this night and the pfSense uses a new address with the new prefix (ping from the webgui works), however the clients still receive the old WAN prefix.The lifetime on the client resets itself every few seconds to 86400 and starts counting down again.
inet6 2003:f1:6704:a81:****:****:****:****/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 86397sec preferred_lft 14397secThe pfSense has got the new prefix. IPv6 address for this interface:
IPv6 Address 2003:f1:670a:c981:****:****:****:**** Subnet mask IPv6 64 -
@mphilippi said in IPv6 connectivity from LAN is lost after PPPoE reconnect:
The WAN prefix changed this night and the pfSense uses a new address with the new prefix (ping from the webgui works), however the clients still receive the old WAN prefix.
The problem is the clients don't change their prefix when a RA with a new prefix is sent out. I don't see how pfSense can do anything to get around that.
-
@JKnott said in IPv6 connectivity from LAN is lost after PPPoE reconnect:
@mphilippi said in IPv6 connectivity from LAN is lost after PPPoE reconnect:
The WAN prefix changed this night and the pfSense uses a new address with the new prefix (ping from the webgui works), however the clients still receive the old WAN prefix.
The problem is the clients don't change their prefix when a RA with a new prefix is sent out. I don't see how pfSense can do anything to get around that.
Do you know why the lifetime of the IP is resetting itself every few seconds? When I issue a new "ip addr eth0" command on the client, the lifetime is always around 86400s.
-
Not off hand. RAs are sent out frequently and they are what tell the client what the prefix is. With SLAAC, the lifetime of privacy addresses is about a week, but the consistent address shouldn't change, other than the prefix.
-
@mphilippi, do you still have only one IP (with the old prefix) or multiple, with old and new prefix?
My next step would definitely be to do a network capture on your client and filter for Router advertisements. As the lifetime is always reset, probably something still sends RAs with the old prefix. 86400/14400 are the default lifetime values on pfSense.
A little story: I once had the strange situation (actually very similar to yours) that something in my LAN still advertised an old prefix. After a network capture on a client it turned out, that a second pfSense that I have (as a VPN gateway) that was actually only a client in the LAN (getting its own IP via SLAAC from RAs of the main pfSense) with RAs theoretically disabled (you even don't see the "DHCPv6 Server & RA" UI when you don't have a static IP on the interface), sent out RAs for the prefix it got via RAs itself. :D At least at that time pfSense had a default configuration that sent out RAs on LAN even if you don't see it in the UI. So the solution was, give the LAN interface a static IP to enable the "DHCPv6 Server & RA" UI, disable the RAs there and switch the LAN interface back to SLAAC. :D
-
@HG said in IPv6 connectivity from LAN is lost after PPPoE reconnect:
@mphilippi, do you still have only one IP (with the old prefix) or multiple, with old and new prefix?
Only one IP with the old prefix.
I'll do the network capture, but there's only one pfSense running per site (changing prefix plan and business static prefix plan of the provider). The sites are not interconnected via VPN.
Since others report the same problem in combination with my provider, I still believe it is a pfSense bug.EDIT:
To make the IPv6 connection work again, it is sufficient to just go to Sytem -> Routing and click on save without changing anything. Thereafter, the clients receive the new address and now show both addresses with the network command. However, the old one is not getting renewed every few seconds and starts to timeout after 24h.
But this will only work until a new prefix is issued by the provider... -
Ok, I ran wireshark on a client and it revealed that the router advertisements come from the pfSense at an interval of 10-15s. The old IP is in the RA.
-
OK, so we know that it definitely comes from the pfSense. That's indeed very strange. But can't be a general issue, because here it works. I have the problem described earlier that the clients still use the old IP address for some time, but the pfSense starts announcing the new prefix as soon as the reconnection happens, e.g. after the DSL Sync got lost. Must be something different in your scenario/configuration...
-
You also have to look at how often DHCPv6-PD executes and whether it does after PPPoE comes up. I have a capture of DHCPv6 at boot up and the first renewal and it's over 22 hours between them.
