OPNsense Forum

English Forums => 26.1, 26,4 Series => Topic started by: FarmServer on February 19, 2026, 01:28:40 AM

Title: Client is being assigned bogus primary dns nameserver
Post by: FarmServer on February 19, 2026, 01:28:40 AM
I have a computer that needs to connect to a corporate network via ipsec that is having issues connecting using its ipsec client. My opnsense firewall and zenarmor do not seem to be blocking any connections from this computer. The only suspect thing I can find with its connection issues is when this computer connects to my wifi sometimes the primary dns is assigned to 192.168.3.41 and the secondary is assigned to 192.168.1.1(the subnet this pc should be on).

192.168.3.x is a subnet I use for wired clients but none are broadcasting dhcp. 192.168.1.x is my wifi subnet broadcast over two access points. the access points are not configured to assign dhcp or dns, they are just antennas.

I am using dnsmasq for dhcp with a dns listen port of 0 which should disable dns as far as I understand. Dhcp ip ranges are defined in dnsmasq for each subnet, everything else is defaults.

I am using UnboundDNS for dns over tls. Its listening on port 53, nothing else is really configured except for cloudflare, quad9, and google dns servers.

No dns is assigned in system > settings > general.

Yet somehow this one pc keeps getting assigned an ip on 192.168.3.x as its primary dns. Its a corporate owned pc so I cant edit anything in its network settings to force it to use different dns name servers. None of my other clients on the wifi subnet are getting assigned anything more than 192.168.1.1. In fact, this one pc is the only pc getting assigned a primary and secondary dns. The other windows clients are only being assigned 192.168.1.1 as a primary dns and no secondary.

Im a bit stumped as to what could be assigning this dns address. Is there anywhere in opnsense I should look, or some setting to better force dns assignments to this client? It seems to need a more explicit declaration of primary/secondary dns but I cant do that without admin rights on the corporate pc, which I wont ever get.

Thanks for the help
Title: Re: Client is being assigned bogus primary dns nameserver
Post by: nero355 on February 19, 2026, 03:27:24 AM
Quote from: FarmServer on February 19, 2026, 01:28:40 AMYet somehow this one pc keeps getting assigned an ip on 192.168.3.x as its primary dns. Its a corporate owned pc so I cant edit anything in its network settings to force it to use different dns name servers.
Maybe it's a hardcoded IP address of the Corporate DNS Server ?!

What happens when you boot the PC without a network connection : Is the Primary DNS Server 192.168.3.41 still there ??
Try it a couple of times and check what happens...
Title: Re: Client is being assigned bogus primary dns nameserver
Post by: meyergru on February 19, 2026, 10:02:50 AM
If that is two different IPs from different subnets on WiFi and ethernet, then I guess your claim that there is no active DHCP server on the wired network is false. Setting DNS to port 0 may disable the actual DNS service for DNSmasq, but that does not say anything about what IP any DHCP server announces for the DNS service.
Title: Re: Client is being assigned bogus primary dns nameserver
Post by: LisaMT on February 19, 2026, 04:07:05 PM
Don't use Dnsmasq.  Kea/Unbound.
Title: Re: Client is being assigned bogus primary dns nameserver
Post by: FarmServer on February 19, 2026, 10:35:14 PM
Quote from: LisaMT on February 19, 2026, 04:07:05 PMDon't use Dnsmasq.  Kea/Unbound.

This was also happening with the older isc dhcp service.

I also disconnected my 192.168.3.x subnet and turned all the PCs off to check and see of one of my computers was the rogue DHCPer but it didn't change what was happening.

I may have found the issue, or an issue at least. It seems when the corporate PC connects to my wifi but not the IPSEC connection it only gets assigned the 192.168.1.1 dns server like everything else. It only acquires the 192.168.3.41 primary dns address when it connects to the corporate network via IPSEC. Which seems like a lazy and incorrect use of subnet addressing on their end. Perhaps the coincidence of me also having a 192.168.3.x subnet was freaking it out.

I took the equally lazy path and just reassigned my 192.168.3.x subnet to a different address further away from 3 and I have yet to hear any complaints.