IPv6 unbound problem
-
Hi!
My IPv6 setup worked for a couple of years, but now unbound restarts every couple of seconds and the router is running with very high CPU values. The general log file also has frequent "/rc.newwanipv6: rc.newwanipv6: Info: starting on pppoe0." entries.
I am not sure when it started to happen, but it could have been the udpate to 2.4.4.
My configuration is as follows:
WAN: IPv4 PPPoE and IPv6 DHCP6 (Ipv6 prefix through IPv4, 56 bit delegation size (from ISP), send IPv6 prefix hint)
LAN: IPv6 track interface WAN with id 0
DHCP6: RA unmanaged
Firewall rules: allow any ICMP on WANGetting the IPv6 address from the ISP is not the problem. The irregular behavior starts only when I enable "Track Interface" on the LAN side and restart the router.
Any ideas what I could look at?
-
@jsphgttgns said in IPv6 unbound problem:
LAN: IPv6 track interface WAN with id 0
you should allow any ICMP on LAN, but thats not the point. Turn off DNS Registration in DNS-Resolver config
pfadmin
-
I guess you are referring to the 3 register flags "DHCP Registration", "Static DHCP", and "Open VPN Clients". They were already on "Off", but there's another router in the network that had them all set and they were set recently. I wouldn't exclude some kind of interaction, but I am not sure.
Once there are less guests on the net, I'll enable IPv6 again.
-
None of the registration options are set and allowing SLAAC on the LAN side lets unbound restart every couple of seconds. I am currently going through the log files to find something that could trigger the anomalous behavior.
The general log has many lines that look like these:
/rc.newwanip: Unbound start waiting on dhcp6c. /rc.newwanip: rc.newwanip called with empty interface. /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 80.153.yyy.xxx -> 80.153.yyy.xxx - Restarting packages. /system.php: The command '/sbin/route delete -inet6 ''' returned exit code '71', the output was 'route: : hostname nor servname provided, or not known'
Currently I don't know what is triggering that.
-
It seems as if radvd is not working properly. Either there is no routing info, or unbound marches to a different drummer. I think the next step is to find out what the ISP actually sends and evaluate that with Wireshark. It could be problem a problem with the subnets and prefix sizes.