IPV6 does not recover from WAN link cablemodem reset
-
Cablemodem reset destroys IPV6 connectivity till next pfSense reboot!!!
System log attached. Cablemodem reset starts around 00:15:00.
After reset, but prior to registration, cablemodem runs internal DHCP server serving 192.168.100.x addresses with 30 second lease. Once registered, cablemodem shuts down internat DHCP server and passes DHCP requests on to ISP's DHCP server that then provides real IPV4 network address.
Some observations from the log:
dyndns is not restarted when WAN interface switches from 192.168.10 to network address and continues to try to use 192.168.100.10!!!
dhcp6c (WAN dhcpv6 client) times out a few times then gives up prior to modem completing registration. This might explain why the WAN interface never recovers IPV6 connectivity.
system.log.txt -
Yes, this is a known problem; see your other thread. I don't believe there is a reliable workaround at this point.
-
Put a network switch between the modem and firewall interface. Provided you don't need an address renewal during the modem reset the firewall will interpret the modem reset as packet loss. If you don't have a smart/managed network switch to use vlans on you will need to dedicate a switch for the modem/firewall interface.
-
Except the problem isn't that the modem disappears, but rather that it gives out short-term private v4 leases while it's waiting for the upstream connection to come back up, but does not also advertise a temporary v6 prefix. This confuses the v6 code on pfSense, causing both the DHCPv6 client on the WAN side and radvd on the LAN side to shut down. At that point, the only way to get them back up appears to be a reboot.
-
A dumb switch between the modem and the LAN interface won't work. The IPV6 address you'll get after the modem completes registration is not likely the same as what you had before the modem reset. By putting a switch between the modem and the WAN port all you are doing is preventing pfSense from seeing that the link went down. It will continue using the old IPV6 addresses till the lease expires (in up to 4 days) which aren't the ones currently assigned by the ISP.
The solution seems to be to make the DHCPV6 client keep retrying to acquire an address for a longer period of time before giving up. Presently it retries twice, which is not long enough to allow the modem to complete registration after reset. It would be nice if cablemodems would run a temporary DHCPV6 server prior to registration and assign short lease private IPV6 addresses prior to registration, as they do for IPV4. For whatever reason neither Broadcom or Intel (TI) based cablemodems do!
Is there a pfSense way to take down a WAN link interface and bring it back up? Something like the Linux ifdown and ifup scripts. That would at least work around the need to reboot the entire box when a modem reset occurs.
-
Finally got to talk to the modem code developers at Broadcom (where I work) about this IPV6 problem, and they pointed out how pfSense is misbehaving in its role as an IPV6 router.
First of all, they explained that the modem handing out temporary (short) IPV4 leases when it is not registered is just a hack to allow management access via SNMP from the LAN side prior to registration. There is no intent to ever implement such a scheme for IPV6, primarily since it doesn't make sense!
As for link bring up, a well behaved router will first solicit an IPV6 route. If the request times out then a back-off algorithm is implemented where it retries after 2, then 4, then 8 seconds, etc… , up to a maximum of 5 minutes (or some such arbitrarily long timeout). It does so indefinitely till it receives an appropriate route advertisement. Only when it has proper IPV6 routing data does it initiate the DHCPV6 client to acquire whatever it can't get from RAs, such as DSN servers etc.... It makes no sense to send DHCPV6 requests on a link that cannot reach the ISP's DHCPV6 servers.
The only way an unregistered modem could respond to a router solicitation is to respond with a router advertisement that contains a router lifetime field of 0, which is equivalent to no response at all.
From what I can observe of pfSense, it gives up prematurely on obtaining an IPV6 route, and it launches the DHCPV6 client before it has V6 connectivity.
-
A dumb switch between the modem and the LAN interface won't work. The IPV6 address you'll get after the modem completes registration is not likely the same as what you had before the modem reset. By putting a switch between the modem and the WAN port all you are doing is preventing pfSense from seeing that the link went down. It will continue using the old IPV6 addresses till the lease expires (in up to 4 days) which aren't the ones currently assigned by the ISP.
This is exactly the point. Perhaps Comcast is unique (long lease times for both IPv4, IPv6 and IPv6 PD, effectively static) but the use of a switch between the modem and wan interface of a pfsense firewall works reliably for me. This has worked on two completely different setups at different locations, granted both had Comcast as their ISP. This has worked even when a modem reset occurs multiple times a day.
-
Not the case here with Comcast. After a modem reset, I'll usually get the same IPV4 address I had before the reset, but never the same IPV6 address.
-
I have just stumbled over the same problem. https://forum.pfsense.org/index.php?topic=81543
I thought I'd just mention here that instead of rebooting the whole router it's sufficient to simply hit "save" (without any modifications) on the WAN Interface page and then "Apply Changes" to have everything on the WAN reinitialized including IPv6.
-
I'm not experiencing this with TWC cable modems but I've heard of another user having a similar issue in another TWC market. The dhcp6c client has many options which I wish was changeable via the gui but you can change manually..
maybe these threads can help?
https://forum.pfsense.org/index.php?topic=76322.msg426945#msg426945
https://forum.pfsense.org/index.php?topic=73760.0dhcp6c.conf man
https://www.freebsd.org/cgi/man.cgi?query=dhcp6c.conf&apropos=0&sektion=0&manpath=FreeBSD+Ports+8.4-RELEASE&arch=default&format=html
