IPv6 lost on 2.2-RELEASE (Comcast)
-
The issue I've had with comcast and TWC in the past is that I can easily get IPV6 at the WAN. Then can easily get IPV6 at the LANs.
However, when they change the WAN IP, or remote reboot the modem or update anything, IPV6 would die and not reconnect and required a pfsense reboot.
If you get this working in 2.2, please do try a reboot of the modem and let me know if it breaks IPV6 and requires a pfsense reboot.
If its working reliably now on 2.2 without requiring pfsense reboots every time something changes with the modem, I might set up native IPV6 again in a couple of places.
I'll try as soon as I have it working.
I did brute force this problem previously by putting a switch between WAN and the CM so that WAN never goes down.
-
However, when they change the WAN IP, or remote reboot the modem or update anything, IPV6 would die and not reconnect and required a pfsense reboot.
I see Comcast rebooting the modem every day around 11am in CT so I often see the LAN IPv6 tracked address disappearing and requires a re-save on the WAN interface or a full reboot to bring back.
-
Me also - The technical term for that is "Damn annoying"
-
Thank you doktornotor and Chris Buechler!
Deselecting "Block bogon networks" on the WAN interface fixes the issue for now and I'll enable this again when the next release of PfSense becomes available.
Reference: DHCPv6 client pass rules need to come before bogons
-
However I still have an fe80 dhcp6 WAN Gateway
That's expected and not a problem.
and obviously nothing LAN side is getting an address. I have "Track interface" and "WAN" for the LAN interface.
As mentioned before, if you played around with the prefix size and/or hint settings, Comcast may continue to delegate the wrong prefix size until your DHCP6 lease with them expires. Take a look at the logs; in particular, look for messages from radvd that would indicate that your announced prefix size on the LAN ends up being anything other than /64. pfSense will blindly set the LAN-side prefix length to ((actual delegation size) + (64 - (configured delegation size))), and anything other than a resulting /64 will break SLAAC for your clients.
Some help on how to force the DHCP6 lease to renew? I have no idea. :-[
-
and obviously nothing LAN side is getting an address. I have "Track interface" and "WAN" for the LAN interface.
As mentioned before, if you played around with the prefix size and/or hint settings, Comcast may continue to delegate the wrong prefix size until your DHCP6 lease with them expires. Take a look at the logs; in particular, look for messages from radvd that would indicate that your announced prefix size on the LAN ends up being anything other than /64. pfSense will blindly set the LAN-side prefix length to ((actual delegation size) + (64 - (configured delegation size))), and anything other than a resulting /64 will break SLAAC for your clients.
Some help on how to force the DHCP6 lease to renew? I have no idea. :-[
[/quote]Never Mind. Setting "DHCPv6 Prefix Delegation size" to 64 and checking "Send IPv6 prefix hint" along with unchecking Bogons has fixed my problem.
I guess I'll wait for 2.2.1-RELEASE to turn bogons back on.
-
I had the same issue until I unchecked "Block bogon networks" on the WAN interface. Immediately had an address, and all the computers on the network had IPV6 addresses. Give it a shot. Not sure what this buys me in the security department though…
I have TWC and it was working fine with 2.2 since it came out. Last week I stopped getting an address. Disabling bogon and it is pulled up an address. Thanks
-
I'm in the same boat as you – had IPv6 working just fine on TWC before 2.2, now I cannot get an IPv6 address. I will disable bogons and see if that helps.
-
The issue I've had with comcast and TWC in the past is that I can easily get IPV6 at the WAN. Then can easily get IPV6 at the LANs.
However, when they change the WAN IP, or remote reboot the modem or update anything, IPV6 would die and not reconnect and required a pfsense reboot.
If you get this working in 2.2, please do try a reboot of the modem and let me know if it breaks IPV6 and requires a pfsense reboot.
If its working reliably now on 2.2 without requiring pfsense reboots every time something changes with the modem, I might set up native IPV6 again in a couple of places.
I still have this exact problem on Comcast, running 2.2-RELEASE. I have tried it both with and without the "Use IPv4 connectivity as parent interface" box checked. Other than that I am using the default WAN settings. IPv6 seems to come back reliably on reboot. I also get these log messages (after reboot) that others have mentioned seeing:
Messages at boot:
Mar 10 00:21:20 radvd[24746]: version 1.9.1 started
Mar 10 00:21:20 radvd[24746]: IPv6 forwarding setting is: 0, should be 1
Mar 10 00:21:20 radvd[24746]: IPv6 forwarding seems to be disabled, but continuing anyway.
Mar 10 00:21:20 radvd[24746]: no auto-selected prefix on interface em1, disabling advertisements
Mar 10 00:21:20 radvd[25044]: sendmsg: Can't assign requested address
Mar 10 00:21:20 radvd[25044]: attempting to reread config file
Mar 10 00:21:20 radvd[25044]: sendmsg: Can't assign requested address
Mar 10 00:21:20 radvd[25044]: resuming normal operation
Mar 10 00:21:23 radvd[25044]: attempting to reread config file
Mar 10 00:21:23 radvd[25044]: resuming normal operationAdditional messages:
Mar 10 17:28:39 radvd[25044]: resuming normal operation
Mar 10 19:03:37 radvd[25044]: attempting to reread config file
Mar 10 19:03:37 radvd[25044]: resuming normal operation
Mar 10 19:10:11 radvd[25044]: attempting to reread config file
Mar 10 19:10:11 radvd[25044]: resuming normal operation
Mar 10 22:08:38 miniupnpd[83522]: remove port mapping 12307 TCP because it has expired
Mar 10 22:32:41 miniupnpd[83522]: ioctl(s, SIOCGIFADDR, …): Can't assign requested address
Mar 10 22:32:41 miniupnpd[83522]: Failed to get IP for interface em0
Mar 10 22:32:41 miniupnpd[83522]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 10 22:32:45 radvd[25044]: Exiting, sigterm or sigint received.
Mar 10 22:32:45 radvd[25044]: sending stop adverts
Mar 10 22:32:45 radvd[25044]: removing /var/run/radvd.pid
Mar 10 22:32:45 miniupnpd[83522]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=18): No route to host
Mar 10 22:32:45 miniupnpd[83522]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=18): No route to host
Mar 10 22:32:45 miniupnpd[83522]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=18): No route to host
Mar 10 22:32:45 miniupnpd[83522]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=18): No route to host
Mar 10 22:32:45 miniupnpd[83522]: SendNATPMPPublicAddressChangeNotification: sendto(s_udp=18): No route to host
Mar 10 22:32:48 radvd[69536]: version 1.9.1 started
Mar 10 22:32:48 radvd[69536]: no auto-selected prefix on interface em1, disabling advertisements
Mar 10 22:32:50 radvd[69846]: attempting to reread config file
Mar 10 22:32:50 radvd[69846]: no auto-selected prefix on interface em1, disabling advertisements
Mar 10 22:32:50 radvd[69846]: resuming normal operation(No IPv6 addresses at this point)
-
Mar 10 22:32:41 miniupnpd[83522]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
In light of that line, any chance your modem lost its uplink around that time? It will then issue a 192.168.100.0/24 IP to your pfSense box but not respond to DHCP6 requests, which in turn causes the DHCP6 client on pfSense to exit and it never gets restarted.
-
Mar 10 22:32:41 miniupnpd[83522]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
In light of that line, any chance your modem lost its uplink around that time? It will then issue a 192.168.100.0/24 IP to your pfSense box but not respond to DHCP6 requests, which in turn causes the DHCP6 client on pfSense to exit and it never gets restarted.
I'm assuming that's what happened. I loose IPv6 every day or two, but this line doesn't always appear. I thought that the "Use IPv4 connectivity as parent interface" option was supposed to address the scenario you described above.
-
I had the same issue until I unchecked "Block bogon networks" on the WAN interface. Immediately had an address, and all the computers on the network had IPV6 addresses. Give it a shot. Not sure what this buys me in the security department though…
I have done this and I did get the IPv6 right away as well. What is strange is that it was checked from the start, and the IPv6 was working just fine.
Only some reboots later did the IPv6 stop working. Strange…
System: Advanced: Admin Access
Bogon Networks :: Update Frequency I set it to daily
The frequency of updating the lists of IP addresses that are reserved (but not RFC 1918) or not yet assigned by IANA.After getting the IPv6, i went ahead and checked the block bogon networks, and the IPv6 stayed. (Will monitor to see if it changes upon reboot in the future.)
Try this and see if it works for you.
-
There's a bug regarding IPv6 not returning after modem reset… I added some comments back in February about it, even with the "Use IPv4 connectivity as parent interface" option enabled.
https://redmine.pfsense.org/issues/3290
-
@virgiliomi:
There's a bug regarding IPv6 not returning after modem reset… I added some comments back in February about it, even with the "Use IPv4 connectivity as parent interface" option enabled.
https://redmine.pfsense.org/issues/3290
Thanks for the pointer, I'm now watching this issue. It sounds like your experience is the same as mine.
