DHCP6c and Unbound DNS Server Boot-Up Configuration Failure
When running my router with ‘Track Interface’ and dual IPv4/IPv6, using unbound as a local DNS server bound to only internal interfaces: LAN, LAN IPv6, and LAN IPv6 Link-Local, the DHCP6c service start-up is clobbering the FreeBSD kernels’ IPv6 auto link local LAN ( net.inet6.ip6.auto_linklocal=1) assignment over to a default address of fe80::1:1 and causing ubound DNS server to fail to startup for local service which still hold the original address in unbound.conf, and which it cannot ‘bind’
socket to, crashing on startup. Details in attached PDF writeup.
add fe80::1:1 as an alias. Issue #9998
(cherry picked from commit 24da61c68c91ea1d1cb7214aeeddd6c9ae741ce5)
#2 Updated by Jim Pingle about 2 months ago
Once upon a time we started using fe80::1:1 as a predictable local address sort of like 192.168.1.1, but I don't think it ever really worked like we wanted. Browsers won't properly connect to scoped link local addresses, so most of the point of it is moot. We can probably remove any references to fe80::1:1 in the code at this point.
#3 Updated by Eric Veum about 2 months ago
Patch file supplied to set fe80::1:1 as an IPv6 alias (and NOT remove the native IPv6 link-local), to clean up the interface_track6_configure() function.
That should be backward compatible with anything using fe80::1:1 as well. My unbound DNS starts up clean when the router reboots finally.
Could you review/merge the fix here, please Jim/Victor -- Thanks!
#4 Updated by Jim Pingle about 2 months ago
To review that properly for inclusion, it must be submitted as a pull request on Github: https://docs.netgate.com/pfsense/en/latest/development/submitting-a-pull-request-via-github.html
#9 Updated by Rick Coats 28 days ago
Isn't it a potential issue when you use a fixed ip such as fe80::1:1 that another router or host has already claimed this ip?
Shouldn't it go through the neighbor discovery process for it's link local address?
I could envision 2 pfsense routers connected to the same interface, each have separate WAN interfaces and different Prefixes for redundant paths. If they are both trying to use fe80::1:1 it would fail I would assume.
This configuration is a perfectly valid configuration for ipv6.
#10 Updated by Jim Pingle 25 days ago
- Status changed from Resolved to Feedback
It might be, though with IPv6, DAD will typically kick in and one of them will back off using the address automatically.
I'm thinking maybe it would be better off to just remove this. I'm not sure anyone is actually relying on it, and if someone is, they could add it as a VIP if they really need/want it.
(1) Rick - there is no WAN interface taking the alias fe80::1:1 -- its only on the IPv6 LAN interface. none of the routing advertisements on the LAN would be using it actually, if you review the PDF attached.
(2) On a WAN IPv6, yes there might be some issues doing the same, but that is not the situation with this alias as its only LAN. This is not done on all interfaces.
(1) The 1-liner mwexec setting the LAN link local alias can likely removed, yes. Services are actually using the link-local IP, which were not starting up on boot because of the old redefinition of the link-local, which is the reason for the bug. Since I dont have a full suite of component and unit test, the patch file supplied to you made the additional LAN6 alias.
(4): HA comment: If you are using a HA pair, yes, they'd both have the same hard-coded alias, so that would seem problematic. That would happen with the old code base using the hard-coded link-local, and with the patch/fix supplied as well (same BEFORE/AFTER).
(5): Service/Socket Bindings (CORE ISSUES OF BUB): What is needed is to have the auto-assigned link-local used, as the FreeBSD kernel/IP stack is now designed to do. Outlined fully in write-up. It looks like the whole commit was reverted, which does not solve the issue for DHCPv6 and DNS services configuration. The fix without the IP alias or link-local redefinition to fe80::1:1 statement is needed.
#14 Updated by Rick Coats 25 days ago
Jim Pingle wrote:
He's talking about two routers attached to the same LAN, not WAN. For example, an HA pair. Or a case where you have a separate router for another purpose (e.g. dedicated VPN router or using another circuit isolated to its own router for whatever reason).
This is what I am talking about, internal side of the network where you have more than one router on a network link.
So this is an existing implementation issue that also affects those trying to use multiple prefixes in a single subnet. I am thinking especially those trying to use ULA in combination with GUA addresses for critical items such as dns servers where the ISP providers change prefixes.