If you can confirm I'll get this into 22.1.1 and work on the other implications later.
14:29:28.321436 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 331) 100.127.255.1.67 > xx.xx.xx.xx.68: [no cksum] BOOTP/DHCP, Reply, length 303, xid 0x29719d56, Flags [none] (0x0000) Your-IP xx.xx.xx.xx Client-Ethernet-Address xx:xx:xx:xx:xx:xx Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 100.127.255.1 Subnet-Mask Option 1, length 4: 255.192.0.0 Default-Gateway Option 3, length 4: 100.127.255.1 Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4 Lease-Time Option 51, length 4: 300 Classless-Static-Route Option 121, length 23: (192.168.100.1/32:0.0.0.0),(34.120.255.244/32:0.0.0.0),(default:100.127.255.1) END Option 255, length 0
34.120.255.244 link#4 UHS igb0192.168.100.1 link#4 UHS igb0
As a side note, I still see in Overview the IPv6 DNS servers gathered from DHCPv6 but they don't end up in the route table, not sure what is different for IPv6 ? Maybe not the same script or part of the script ? That would be what we would also like the IPv4 DNS to do I think (show up in the Overview but not in the routes). Anyways, just to mention that the IPv6 vs IPv6 behaviour seems different to DHCP learned DNS and no issue there, it works as expected for me. Could it be because I have prefer IPv4 over IPv6 enabled ? I doubt it...
And yes, I totally agree that it would be very nice in the Overview to still "see" everything that gets pulled from DHCP even though it is ignored as per my current configs.
If I could push my luck on what should also be in Overview: see any routes also being pushed through DHCP, like Starlink does for instance. Those routes end up in the route table (as they should since we respect what DHCP sends us). But that will be for some other time (DHCP learned routes in Overview), you've successfully resolved the initial issue of this post.
Also, maybe in the future, we could add an option to the DHCP client interface config to actually ignore those routes as well, like for DNS. I see many reasons, including route hijacking, security or traffic management that would justify this. I'll open up a "feature request" or something maybe for this one at some point.
However, even though they are there, they don't seem work properly for some reason. I'm still trying to figure out why, maybe because of multi-wan or some nat issue but it was already not working in pre-22.1 so it's nothing related to this version. I'll continue to troubleshoot this part that had been bugging me for months and I'll let you know if I find something.
<dnsallowoverride>1</dnsallowoverride> <dnsallowoverride_exclude/>
if (isset($syscfg['dnsallowoverride'])) { $search = array_merge($search, get_searchdomains());- foreach (get_nameservers() as $nameserver) {- $resolvconf .= "nameserver $nameserver\n";+ foreach (get_nameservers(null, true) as $nameserver) {+ $resolvconf .= "nameserver {$nameserver['host']}\n";+ $routes[] = $nameserver; } }
I'm trying to properly identify what is happening with and without the patch. This is way more complicated than what I first thought however and I see many different behaviours depending how the DNS are learned. On initial bootup, on a forced DHCP reload from the interface overview or on an automatic DHCP renewal, they all behave differently. Some of those may be desired or not, I guess... I mean, you may want to have specific routes to the DHCP-learned DNS servers if you have many WANs since you may want to reach those learned DNS only through the provider that gave them to you. But a problem arise when you have manually defined routes, or gateway monitoring using those DNS address on the other provider or when you have configured DNS using specific gateway, etc... When that happens, who should win ? The configurations in opnsense or the DHCP-learned ones ? I believe it should alway be what we manually configure or enforces, not what is dynamically learned, else, remove your configs and let the dynamic stuff do his stuff, right ?
This is still subject to a lot of funky races for overlapping hostroutes either by ISP, manual DNS, gateway monitors or static routes.
Also take into account that I use one of the DHCP learned DNS as the IP address for gateway monitoring and that's how I discovered I had an issue in 22.1 vs 21.x. I think opnsense adds routes to this IP to make sure it uses this specific route/gateway for monitoring marking the gateway as up (which is how it should be). Since this opnsense-added route for monitoring for gateway A was getting overridden by the DHCP-learned DNS IP from gateway B, the gateway A monitoring wasn't working properly anymore. The monitoring for gateway A was going through gateway B (instead of the configured A) after DHCP renewal happened on gateway B because dhcp client triggered the addition of the static route when it learned this DNS IP on gateway B, which happens to be the IP address I use for gateway A monitoring in the gateway A configuration.
WITH the patch and "Allow DNS server list to be overridden" enabled (Me testing for others for this patch:Behaviour is the exact same as above on all 3 points, as if the "Allow DNS server list to be overridden" is completely ignored even though it is properly configuredThe part that pertains to this in the patch seems here. This seems to generate an empty list of what is learned as only the configured DNS from the settings ends up in the resolv.conf file.Code: [Select] if (isset($syscfg['dnsallowoverride'])) { $search = array_merge($search, get_searchdomains());- foreach (get_nameservers() as $nameserver) {- $resolvconf .= "nameserver $nameserver\n";+ foreach (get_nameservers(null, true) as $nameserver) {+ $resolvconf .= "nameserver {$nameserver['host']}\n";+ $routes[] = $nameserver; } }Unsure if it is related or not ?Also, to be sure we're testing against the same version of opnsense here's my version: 22.1.1_3
