Hundreds of ipv6 rule errors appearing in dashboard –- brings down the WAN
-
Hi All,
We are loving v.2.2 which is great stuff.
I have also taken the opportunity to deploy IPv6. This is a tiny network with 8 devices on it on Comcast cable. There is not much going on, no portal, no auth', just 1 IPsec tunnel and some ACL's, that's it.
The only issue is stability. About once a week or so, the traffic on the WAN only stops flowing. I login to the Dashboard & check it out. I keep fussing with services, stopping, starting, etc, to see if one of those services has anything to do with it. It appears not. The only thing I have found so far to restore connectivity is hitting release/renew on the WAN interface.
When I login, the dashboard shows hundreds of the following type of example:
03-07-15 09:06:21 [ There were error(s) loading the rules: /tmp/rules.debug:190: no routing address with matching address family found. - The line in question reads [190]: pass in quick on $WAN $GWWAN_DHCP6 inet6 from 2601:7:2280:5f6::/64 to any tracker 1422148174 keep state label USER_RULE: allow all ipv6]
Any one know why this is happening? or what I can do about it?
I dont want to disable ipV6 but I might have to if the rest of the folks keep complaining that their WAN goes away for 1 hour every 10 days.
Thanks so much !
Jason
-
Comcast lease renewal ?
We need to know, to see your config. At least to begin with:
[Interfaces: WAN] and [Interfaces: LAN] screenshots ?
-
What is needed is a option or a patch or package that will allow the option to reset the WAN interface when it becomes impossible to ping the gateway or some distant IP with IPV6.
Its possible I'm working with old info and that this has been solved, but I had to remove native TWC IPV6 over this same issue.
-
Here are 2 screenshots that I hope help. I am happy to test or try anything that any one feels might be helpful. If we do, it will likely only take a week to have results.
The other poster sadly had to abandon ipv6. It looks like he was on Time Warner Cable while I am on Comcast (residential).
There does seem to be something broken here, I do not know what it is. I read through the XML backup file the other day to see if I saw something amiss, but do not see anything.
Thanks all.
Jason
-
@Sjobeck:
Here are 2 screenshots that I hope help. I am happy to test or try anything that any one feels might be helpful. If we do, it will likely only take a week to have results.
…The config looks OK. If you do not get a changed IPv6 every renewal, then you could test i.e. 2601:7:2280:5f6::1/64 for LAN as Static i.s.o. Track Interface.
-
Thanks. Appreciated. I could try that.
I strongly do not think that is not a "fix" for the issue. That is a work-around.
I think there is something in the code that is wonky. I wish I knew the code around "ipv6 DHCP interfaces" it well enough to offer an intelligent suggestion. I hope someone else out there does. I wonder if you think this warrants being submitted as a bug. I think it does. Something that brings down the interface every 9 days.
Thanks.
Jason
-
@Sjobeck:
…
I strongly do not think that is not a "fix" for the issue. That is a work-around.
...Sure not a fix, but Tracking Interface is not the best setup. You would want (semi-)Static eventually for a robust config.
The connection protocol is also very dependent on the ISP implementation. pfSense's is doing great to satisfy a lot of weird stuff from the other side ;)
-
I agree that they are. I think they/we are keeping-up, so to speak, quite well. I also agree that every ISP is wacky. I also think that Comcast & TWC having some giant percentage of connections represents a deployment that we need to support. It ought to "just work" for such a simply deployment.
-
Just curious. Do you get an different IPv4 every once in a while?
As an example I can do Static config's because my ISP supplies me the same IPv4 & IPv6 every time when doing a cold restart, and while renewal of the lease is every 1 hour when connected. And this is working stable…
-
If it's comcast, the v6 prefix is not static. I've been using v6 on Comcast for a few years now, and I've never seen this issue, and at least as of version 2.2, it really does "just work" for me.
To the OP, your config looks OK to me; any chance that your WAN or LAN links bounce (temporarily go down) around the time you lose connectivity? Also, from your initial post, it sounds like you're losing v4 connectivity as well; is that the case?
-
Oh, one thing that pfSense does not handle well (or at all, really) is if your modem temporarily loses upstream connectivity and starts issuing a bogus 192.168.100.0/24 IP to your pfSense box; unless something has changed recently, that will cause the DHCPv6 client to quit and pfSense never restarts it.
-
Am also experiencing it here on v22.01 many years later, using Comcast.
Was this ever resolved?
-
When this used to be a problem for me, I added the 192.168.100.x IP to the dhcp ignorelist so pfSense would not accept it when offered by the ISP CPE. This definitely helped.
