Ipv6 fails to work after upstream (comcast) router reboot or renegotiation

dopey

I have comcast business with a static /29 ipv4 block and currently requesting a /60 ipv6 block via dhcpv6. The LAN of course is given a /64 out of that /60.

I'm currently configured so that the dns resolver for pfsense forwards to comcast's DNS servers and the dhcpv6 configuration appears to be setting the ipv6 DNS addresses first:
So the DNS server configuration looks like:
127.0.0.1
2001:558:feed::2
2001:558:feed::1
75.75.76.76
75.75.75.75

We've had a slew of outages in the last few weeks with comcast (and i noticed this myself when i had to reboot my comcast router to clear it's arp cache). If the comcast router either is rebooted, or something causes it to renegotiate it's connection, even though i still get the same ipv6 dhcp addresses ipv6 traffic doesn't appear to be passing. This is noticeable because DNS look ups will be incredibly slow due to waiting for the timeouts for the first two ipv6 dns servers.

But even within the LAN, I'm unable to connect to the ipv6 address for the pfsense router. So if the client's dns resolver (/etc/resolv.conf in the case of unix hosts) is configured for the pfsense router's ipv6 address first, it causes an additional timeout.

If I reboot pfsense, everything starts working fine. If I ssh to the pfsense router and attempt to ping ipv6 addresses out the WAN port, it seems to work fine.

I haven't quite figured out what causes this hiccup.

Has anyone seen anything like this or have an explanation? It's really annoying to have to reboot the pfsense router every time comcast goes down or the comcast router has to be rebooted.

I did read a really good article about why dynamic ipv6 is going to suck, as now your local ip address allocation is at the whim of your isp. This alone is making me think that until comcast supports static ipv6, i may as well just disable it -and yes, disabling ipv6 solves the above problem as well.

But, hoping someone has some ideas. Since i can recreate the problem on demand by simply unplugging and replugging in the comcast router, when I get time, I'd like to try to figure out what's causing it, so if someone has ideas of where to start I'm all ears.

razzfazz

Could be related to issue #3519.

Are you using prefix delegation on the LAN side?

dopey

I'm not sure. I don't quite understand ipv6 prefix delegation yet.

My LAN side is configured for track interface (tracking WAN) and prefix id is 0.

Krellan

I'm also on Comcast, running pfSense 2.2.4, and have the same problem.

I'm using almost exactly the same configuration. Can't get more than /64 because I'm on residential, not business. WAN is set to DHCPv6 and prefix delegation size of /64. No other checkboxes are checked for DHCPv6. LAN is set to Track Interface for the WAN, and prefix ID is 0.

IPv4 and IPv6 will both be perfectly working, then if Comcast modem goes down for whatever reason, when it comes back up, only IPv4 will be working. IPv6 will not be present at all. It's not just a matter of losing the IPv6 addresses of the clients, the router's IPv6 address itself disappears. It has only the IPv4 address remaining, which continues to work just fine. However, I miss IPv6.

It looks like a bug in pfSense, because if I reboot pfSense, both IPv4 and IPv6 come right back up! This would seem to demonstrate the problem lies with pfSense and not with Comcast.

Josh

MikeV7896

I had an issue like this, gave pfSense a rest and went back to an off-the-shelf router for a while, and when I came back to pfSense on the next version release (with a new system to run it on), I never had the problem again. Admittedly, it takes a few minutes from when IPv4 returns before IPv6 is functional as well (and I'm pretty sure that's due to my gateway timeout settings, which I increased to prevent false "down" or "delay" alerts), but it is all working properly. I believe I also have the checkbox linking IPv6 connectivity to IPv4 checked as well, so when the IPv4 side returns to normal, the IPv6 side knows to do the same.

If I unplug the coax to my modem from the wall (to simulate maintenance on Comcast's end), leave it unplugged for a few minutes, then plug it back in, everything eventually returns to normal operation.

BTW, as a Comcast residential customer, you can actually request up to a /60 (businesses can request up to a /56). However, if you already have a /64, your existing delegated prefix and DHCP lease needs to either expire (7 days) or be deleted from Comcast's end before you'll be able to get a new prefix.

dopey

Admittedly, I stlil don't understand ipv6 router delegation, but with comcast business, if you have a static IP (/30 or larger) you have to have a comcast provided router. And that router actually requests a /56.

Interestingly i cannot get pfsense to work properly unless I tell pfsense to request a /60 (which I assume it's requesting from my comcast router) and then I get /64s for my lan interfaces.

Over the weekend i had another comcast outage, and the comcast provider router was unable to renegotiate it's connection when the outage was over. (it was overnight, i noticed it went down, went to bed, woke up and saw it was still down and noticed the router was stuck negotiating - rebooted their router, all good). But what was interesting was a bunch of my clients were autoconfigured with 2 Ipv6 addresses. After the outage, the LAN port on pfsense got a different /64 subnet than was previously being used, and a bunch of my machines had autoconfigured a new ipv6 address from the new subnet, but were still hanging on to the old one too.

Not sure what happened there.

Every time I think I'm starting to understand ipv6 better, something else gets tossed in to make it more fun.

dopey

I'm less convinced that the problem is on the comcast configuratoin part if anymore.
I noticed from the firewall logs that most of my ipv6 traffic is simply being blocked when this occurs, and if i attempt to reload the filter rules a handful of times, it eventually starts working.

I did run into a problem with there appeared to be some race condition where my ipv6 rules wren't being applied so maybe it's related to that.

I'm getting centurylink fiber pulled next tuesday, and they use 6rd, so I'm not going to bother digging into the current problem and see what happens when the centurylink connection is up.