Subnet delegation stops working after 10 minutes
-
Hi!
I am experiencing a strange issue with IPv6 subnet delegation and would be glad if anyone could give me a hint or two about what I'm doing wrong.
First a few words about what I'm trying to do: my ISP gives me an IPv6 address plus a /56 prefix through subnet delegation. Since the latest release of pfSense appears to generate invalid RADVD config files I am currently using the daily snapshot from March 15 (i386 nanobsd) which seems to solve that issue.
However, while the connection from the router works reliably, the subnet delegation part does not:
-
After bootup, there is usually an IPv6 address assigned to both, the external interface (vr2) as well as the internal one (vr0). While I seem to remember times when this didn't work either, right now I can't reproduce any issues so we'll assume it works. At this point the client can connect to the IPv6-enabled world just fine.
-
After about 10 minutes the connection stops working, i.e. the client can no longer ping the outside world. On the router it still works fine though so I'm assuming that the issue is related to subnet delegation.
At this point there are several things that I can do:
-
If I start another dhcp6c process, my client's connection suddenly works again. I do get "client6_recvadvert: XID mismatch" errors in the systems logs though plus the additional dhcp6c never seems to receive an actual DHCPv6 reply (it does not even send a request, basically it appears to stop after the solicit/advertise phase).
-
If I kill the currently running dhcp6c process and start a new one instead I do get a proper DHCPv6 reply. Sometimes this restores the client's connectivity, sometimes it doens't (I'm assuming that the case where it doesn't is related to me getting a new subnet but things are a bit hard to reproduce reliably).
-
If I reboot the router things usually work again.
So far the only suspicious thing I could find in the system logs around the time when the network stops working is this:
Mar 16 04:14:04 dhcp6c[22830]: update_ia: T1(187) and/or T2(300) is locally determined
Mar 16 04:14:05 php: rc.newwanipv6: rc.newwanipv6: Informational is starting vr2.
Mar 16 04:14:05 php: rc.newwanipv6: rc.newwanipv6: on (IP address: 2001:X:X:X:X:X:X:X) (interface: wan) (real interface: vr2).
Mar 16 04:14:07 php: rc.newwanipv6: ROUTING: setting default route to 31.X.X.X
Mar 16 04:14:07 php: rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::X:X:X:X%vr2
Mar 16 04:14:07 php: rc.newwanipv6: Removing static route for monitor fe80::X:X:X:X%vr2 and adding a new route through fe80::X:X:X:X
Mar 16 04:14:07 check_reload_status: Reloading filter
Mar 16 04:14:08 dhcp6c[22830]: update_ia: T1(187) and/or T2(300) is locally determined
Mar 16 04:14:09 php: rc.newwanipv6: rc.newwanipv6: Informational is starting vr2.
Mar 16 04:14:09 php: rc.newwanipv6: rc.newwanipv6: on (IP address: 2001:X:X:X:X:X:X:X) (interface: wan) (real interface: vr2).
Mar 16 04:14:11 php: rc.newwanipv6: ROUTING: setting default route to 31.X.X.X
Mar 16 04:14:11 php: rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::X:X:X:X%vr2
Mar 16 04:14:11 php: rc.newwanipv6: Removing static route for monitor fe80::X:X:X:X%vr2 and adding a new route through fe80::X:X:X:X
Mar 16 04:14:11 check_reload_status: Reloading filter(the blanked out addresses are always the same, i.e. every occurrence of 31.X.X.X, fe80::X:X:X:X and 2001:X:X:X:X:X:X:X is identical)
I'm getting two of these events about once every 3 minutes and only the one after 10 minutes uptime appears to correlate with my connection issues so I'm not entirely convinced that the things are related.
Any ideas?
-
-
same here.
however, I tried both pfSense and OpenWrt. both of them do that. so I think it might be the ISP side.
I'm using TWC in NEOhio area.I did a tracert to google.com. first hop responsed very quick(it'm my wan ip), then lots of responses and timeouts
2 * * * Request timed out.
3 9 ms * 10 ms 2605:a000:0:4::2:22b
4 15 ms 9 ms 10 ms 2605:a000:0:4::2:4dc
5 * * * Request timed out.
6 * *
…..