Project

General

Profile

Bug #9998

DHCP6c and Unbound DNS Server Boot-Up Configuration Failure

Added by Eric Veum 2 months ago. Updated 25 days ago.

Status:
Feedback
Priority:
Normal
Category:
DNS Resolver
Target version:
Start date:
12/24/2019
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.5.x
Affected Architecture:
All

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.

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

Associated revisions

Revision 24da61c6 (diff)
Added by Viktor Gurov about 1 month ago

add fe80::1:1 as an alias. Issue #9998

Revision a69c0e4e (diff)
Added by Viktor Gurov about 1 month ago

add fe80::1:1 as an alias. Issue #9998

(cherry picked from commit 24da61c68c91ea1d1cb7214aeeddd6c9ae741ce5)

Revision e832eb98 (diff)
Added by Renato Botelho about 1 month ago

Revert "add fe80::1:1 as an alias. Issue #9998"

It's a 2.5.x only

This reverts commit a69c0e4e0f2337b956aa6dd2d0668d3c2b1a92b7.

History

#1 Updated by Viktor Gurov about 2 months 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?

#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

#6 Updated by Renato Botelho about 1 month ago

  • Status changed from New to Feedback
  • Assignee set to Renato Botelho
  • % Done changed from 0 to 100

PR has been merged. Thanks

#7 Updated by Eric Veum about 1 month ago

Feedback/QA - I've upgraded to 2.5.0-DEV current (2020-01-17 build), and everything is working as intended. Thanks.

#8 Updated by Jim Pingle about 1 month ago

  • Status changed from Feedback to Resolved

#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.

#11 Updated by Eric Veum 25 days 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.

#12 Updated by Jim Pingle 25 days 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).

#13 Updated by Eric Veum 25 days 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.

#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.

Also available in: Atom PDF