IPv6 lost on 2.2-RELEASE (Comcast)
-
Like the subject line. On upgrading to 2.2-RELEASE with no apparent changes to any IPv6 settings I have lost all IPv6 connectivity out the WAN port. I'm using DHCP6 and the Cable modem is a Motorola SB6141 (owned) and the ISP is Comcast in the Houston Texas area.
I've tried restarting everything manually, but it's like the IPv6 connection just evaporated. I checked the SB6141's status page and there's no new firmware or settings that I can see. I never did much IPv6 diagnostics before because I turned it on last year and it "just worked" after copying the pfsense settings from someone else on these forums that had Comcast.
The only odd thing to me is a "%re1" at the end of the "inet6" field in an ifconfig. (Prefix is 64) The IPv6 Gateway field in Interface Status appears to be populated with a valid field too.
Did I miss a README or something is is there strangeness here?
-
Like the subject line. On upgrading to 2.2-RELEASE with no apparent changes to any IPv6 settings I have lost all IPv6 connectivity out the WAN port. I'm using DHCP6 and the Cable modem is a Motorola SB6141 (owned) and the ISP is Comcast in the Houston Texas area.
Works fine here, also with a Moto SB6141, also on Comcast, tho at a different location.
it "just worked" after copying the pfsense settings from someone else on these forums that had Comcast.
Just to be sure, the proper settings for your WAN interface on Comcast are these:
- "Use IPv4 connectivity as parent interface" should be unchecked.
- "Request only a IPv6 prefix" should be unchecked.
- "DHCPv6 Prefix Delegation size" has to be either "none" or 60 and above, but beware that changing this setting will break your connectivity until your lease expires.
- "Send IPv6 prefix hint" must be on if the previous setting is set to anything other than "none" or "64".
The only odd thing to me is a "%re1" at the end of the "inet6" field in an ifconfig. (Prefix is 64) The IPv6 Gateway field in Interface Status appears to be populated with a valid field too.
The "%re1" is expected for link-local addresses (fe80::…). Is that the only v6 address you have? Also, is this your LAN or WAN interface?
Have you looked in the various log files?
-
I'm in a very similar situation. I am also on Comcast and when release 2.2 came out I rebuilt my firewall from scratch using my documented configuration. IPv6 worked for a few weeks then I would lose the IPv6 address on the WAN about once a day, and then more recently multiple times a day. Now I haven't been able to get an IPv6 address for the last 2 days.
I'm using the following on the WAN interface:
Use IPv4 connectivity as parent interface = unchecked (default)
Request only a IPv6 prefix = unchecked (default)
DHCPv6 Prefix Delegation Size = 60
Send IPv6 prefix hint = checkedI set my other interfaces to use Track Interface.
-
WAN:
IPv4 parent IS unchecked.
I've tried none, 60, and 64 as the prefix both with and without hint checked.
LAN:
Set to track WANI have a valid link local on WAN (re1), and the gateway is also an fe80
Can I do some verbose logging and try and bring the IPv6 up manually on WAN to look for any errors?
-
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 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…
https://redmine.pfsense.org/issues/3395
-
OK, unchecking bogons (<bleep>ing regression!) plus a reboot has given me a WAN IPv6 and ping6 confirms on the pfSense system itself. Thanks!
However I still have an fe80 dhcp6 WAN Gateway and obviously nothing LAN side is getting an address. I have "Track interface" and "WAN" for the LAN interface.</bleep>
-
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.
-
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.
-
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.
