Comcast IPv6 works for 1-2 days, then stops routing
-
@jknott I don't see how floating rules could possibly be the problem, given that it works for a few days before it breaks.
This did seem to start when I updated from 2.4.5-p1 to 21.02, which of course broke IPv6. I then went back to 2.4.5-p1 and loaded my configuration file that I took from before the upgrade, but IPv6 never worked properly after that. Comcast does claim that they pushed an update to the cable modem at around the same time, so I thought it definitely had to do with that. I wonder if it's possible that the configuration reload after the reinstall didn't set something properly?
-
I'm just tossing out ideas of things to consider. Is there anyone else here on Comcast with the same problem? How do the packet capture compare when it's working vs when it's not? Given it fails after 2-3 days, it might be something with with the lease time, if it's that long. Have you captured the DHCPv6 sequence? You'll find the lease times in one of the reply XID packets. What happens if you disconnect/reconnect the WAN cable?
-
@jknott No, disconnecting and reconnecting the cable does not cause the behavior to change. Even a full reboot does not seem to fix the issue. The DHCPv6 packets contain a Preferred lifetime of 86400 and Valid lifetime of 172800.
-
@jknott Update: been working for about 5 days now. Was trying to get more packet capture logs and noticed something strange: ipv6 pings were failing from devices behind the pfSense, but succeeding from pfSense's ping tool from the interface associated with their VLAN. This was unlike in the past, where both seemed to succeed or fail together.
Digging into why the pings would succeed from pfSense itself but fail for devices behind the router, I looked into the firewall rules. Eventually I ended up removing a rule that was blocking IPv6 traffic, if it was sent to fe80::/10 (actually what I did was I had a rule that blocked all traffic sent to any "private address", in the sense that I had a rule at the end of the chain for traffic on that VLAN that passed all traffic sent NOT to a private address, and fe80::/10 was on the list of private addresses). Well, once I removed fe80::/10 from the definition of "private address", things actually started working, and have now been working for 5 days straight.
I'm still trying to figure out why it ever worked for so many months (actually 2+ years) with this rule in place, if that was actually the problem. It should also be noted that when traffic was refusing to route before, I never was able to get pings through, even from pfSense's "ping" tool when I selected individual VLANs as the source address, so I also wonder if Comcast actually fixed something. It's possible that there were two simultaneous issues here.
-
Yeah, blocking link local addresses would cause problems, as IPv6 relies on them for so much.
My rule for private addresses includes the RFC1918 blocks and all ULA. As link local doesn't pass through a router, there's no need to block it.
-
@jknott Yeah, I should have known that. But I simply looked at the table of "private addresses" and blindly added them all to a rule.
Do you have a clue why it would have worked for so long before failing? Why it even worked at all (for approximately 2 days) prior to February of this year? How could it have worked at all if IPv6 needs link-local addresses in order to operate?
-
No idea.
-
@jknott How do you block inter-VLAN traffic in your setup? With IPv4, you can just block RFC1918 addresses, but for IPv6, they're public, and since (for Comcast) they are subject to change, I've had to create rules to block access to every other VLAN I don't want each VLAN to have access to, i.e. reject traffic to "LAN net".
-
You have to specifically allow routing between VLANs. So, just create rules to pass what you want.
-
@jknott I don't think that works. Specifically allowing routing you want means rejecting traffic by default (when it reaches the end of your chain of rules). But if you're rejecting anything unknown, then you have no internet access, since "local" IPv6 addresses are public ones and there's no way to distinguish those from internet addresses. If Comcast changes my address block by giving my router a new block via DHCPv6-PD, then my old addresses then become external internet addresses and should be routable from any VLAN that has access to the internet.
-
Here's an example. This is for my test LAN, but would be exactly the same on a VLAN.
I had to create both those rules to allow IPv4 & IPv6 from my test LAN to anywhere else. If I hadn't created those, I wouldn't be able to reach anything beyond the test LAN.
-
@jknott Yep but if you have a rule like that, you have to specifically block everything you don't want to allow above it, right? Like routing between that VLAN and another VLAN.
-
You allow only what you want to. In this case, I didn't want to block anything. On the other hand, my guest WiFi VLAN is configured to allow only pinging the interface or going out to the Internet.
