Bug #9998
closedDHCP6c and Unbound DNS Server Boot-Up Configuration Failure
Added by Eric Veum over 4 years ago. Updated over 3 years ago.
100%
Description
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.
Files
pfSense - DHCP6c and Unbound Boot-up Configuration Failure.pdf (377 KB) pfSense - DHCP6c and Unbound Boot-up Configuration Failure.pdf | DHCP6c and Unbound startup example failure, writeup | Eric Veum, 12/24/2019 01:56 PM | |
etc_inc_interfaces_inc.patch (761 Bytes) etc_inc_interfaces_inc.patch | Eric Veum, 01/13/2020 11:18 AM |
Updated by Viktor Gurov over 4 years ago
I found that the interface_track6_configure() function switches original link-local address to fe80::1:1
Why do we need to remove the original local-link address?
What if we add fe80::1:1 as an alias?
Updated by Jim Pingle over 4 years 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.
Updated by Eric Veum over 4 years 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!
Updated by Jim Pingle over 4 years 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
Updated by Viktor Gurov over 4 years ago
Updated by Renato Botelho over 4 years ago
- Status changed from New to Feedback
- Assignee set to Renato Botelho
- % Done changed from 0 to 100
PR has been merged. Thanks
Updated by Eric Veum over 4 years ago
Feedback/QA - I've upgraded to 2.5.0-DEV current (2020-01-17 build), and everything is working as intended. Thanks.
Updated by Rick Coats over 4 years 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.
Updated by Jim Pingle over 4 years 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.
Updated by Eric Veum over 4 years ago
(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.
Updated by Jim Pingle over 4 years ago
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).
Updated by Eric Veum over 4 years ago
(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.
Updated by Rick Coats over 4 years 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.
Updated by Jim Pingle almost 4 years ago
- Category changed from DNS Resolver to Interfaces
- Affected Version deleted (
2.5.x)
Updated by Viktor Gurov over 3 years ago
- Status changed from Feedback to Resolved
2.5.0.a.20210201.2350
works as expected