DNS Forwarder - Domain Override
I am supporting a setup that someone else has configured and as such I am unsure about something that is configured on there.
We have a load of sites using Pfsense boxes as firewalls and VPN tunnel connectors back to our HQ. Thats all fine and working. But on site, we have an issue whereby some people with laptops who are on the domain (all other computers there are not on the windows domain), where they cannot connect to outlook.
Now having done some troubleshooting I noticed in the DNS forwarders there is a Domain override setting of 172.16.8.3@pfsense local IP. Now if I change that to just the pfsense local IP it works fine. But if I leave it for a little while and go back into the DNS forwarder it automatically puts in another entry underneath the one I edited with that same 172.16.8.3@…
I have tried ticking/unticking Allow DNS server list to be overridden by DHCP/PPP on WAN option but still the same problem. I have tried restarting the dns service and then deleting... deleting then restarting, but still it persists on re-adding that entry in.
So how would this be achieved? The router is not configured with that 172 address anywhere do it's not being pushed from there. That 172 address is the subnet for the DNS servers in my HQ but that address I cannot find anywhere.
Could anyone help or point me in the right direction here?
Many thanks in advance.
No no no no no. Computers on AD must point to AD DNS, not the pfSense forwarder.
So, how do I stop it from automatically getting this entry inserted into Domain override so I can correct it?
Which entry? There are no automatic domain overrides added anywhere. Not to mention, you need to assign the proper DNS servers via DHCP. How's domain override even relevant here? The AD clients should never hit the DNS forwarder directly.
There is a Domain override setting in my DNS forwarder that gets automatically added in. If I delete it or change it then it automatically comes back.
If I change it so that it is not pointing to the 172.16.8.3@pfsenseip then Outlook works fine. Thats not the issue I am having here. The issue is that pfsense keeps getting this setting back in Domain override.
And the proper DNS servers are configured on the box. They point back to my main firewall which also handles all my Ipsec Tunnels and does the NATTing when the traffic comes back into my main network. Thats the primary DNS, the secondarys are the ISP DNS for that particular connection.
But like I say, the issue here is that when that 172.16.8.3@pfsenselocalip is in Domain overrides then it causes me problems on my laptops. Change it to just the pfsenselocalip and it is fine. When it automatically adds it back a few minutes/moments later then it starts causing problems again.
So I need to find out where or how a Domain override could get automatically added to my pfsense box.
Well, let me repeat:
- there's nothing automatically added here. (Also, I cannot see what is 172.16.8.3@pfsenselocalip supposed to mean in the first place, maybe finally post a screenshot).
- even if there was, it does not matter in the least, the clients are supposed to use the AD DNS servers, which all supposed to have all the DNS records for that domain. Not your pfsense box, not your main firewall box, not any other DNS that does not hold the AD zones.
- so, even if you set up the pfsense box as forwarder for those AD DNS servers, they won't hit any override either, neither directly, nor indirectly.
Well. I would disagree. Because every time I amend the Domain overrides and get it working it re-adds (of it's own accord) this entry at the bottom as shown on screenshot.
I think perhaps you are getting a bit confused as this setup is not what you would call standard.
The main firewall (Palo Alto)in my HQ is what all the pfsense boxes connect back to establish their Ipsec tunnels and what they use as their primary DNS as we push all traffic back through the VPN tunnel and onto our network. The local Pfsense boxes all act as DHCP servers which the laptops connect to and through a patch written by the previous engineer, give them a locally pre-assigned IP address. Then, through the Ipsec tunnel they come back into our main network and onto the Exchange server. These networks are all recognized on my main HQ network and then NAT'ed where they need to go via my Palo Alto Box.
I can go a bit further into the setup if you are still not sure. The fact is that when I remove/amend that 172 domain override then they start working. I don't see this can be coincidence as I have done it on about 5 sites now and all are showing the same thing happen. Take it out/change it… works.... when it then re-enters it automatically... problems.
That entry is totally invalid in the first place. No idea how it gets there.
Yes, I thought it was invalid too when I first saw it. But I am scratching my head as to why it keeps re-adding.
I will say though, I came into this setup blind as the previous guy who set it all up vacated the position before I came onboard and he left no documentation to explain why he set things up the way he did. So if you think there is a better way to do it or to get around (without screwing up what is already in place mind) this I am open to listening.
Well, download configuration backup, search for the offending entry and related stuff, edit it out and restore the backup?
Good idea that. I'll give it a try. I have already tried manually editing the /cd/conf/config.xml file and saving it. But no luck.
I'll try the backup option and let you know how that goes.
Nope. It stayed like that for a minute or two. Then that entry came back in.
Any other suggestions?
Looked in the system logs. This is what I saw relating to this.
dnsmasq: using nameserver 172.16.8.3#53 for domain….....
No, no idea what's putting the nonsense back. Maybe just reconfigure the thing from scratch.
Crud… not something I relish the prospect of. Especially when I have about 30 such boxes out on the field.
But I appreciate the advice. If anyone else can think of anything then I would love to hear it.
For the record, "@192.168.55.3" simply indicates that the DNS requests to 172.16.8.3 are sent out with a source IP of 192.168.55.3 - this is often necessary to specify, so that the DNS requests have a source IP that the remote DNS server can reply/route back to. Particularly in a VPN network when routes to the VPN tunnel end-point addresses may not always be known at the remote DNS server…
That entry should not come back! If you are able to delete all the Domain Overrides entries, look in config.xml and see that they are gone, then you wait a bit and this comes back, then I can only assume there is some custom code added to your system to do this.
and through a patch written by the previous engineer, give them a locally pre-assigned IP address
Are there other special "patches" like this on your system/s?
Perhaps look in cron (easy/GUI way, install the pfSense cron package) and see if there is a cron job running every few minutes that looks "unexpected/odd".
Thanks for that. And yes, on inspection there seems to be a vpn_monitor.php script that is run every 5 minutes to put that back in… Looks like the script runs through and if it detects the main Ipsec tunnels are not online then it enables the Failover Ipsec tunnels.
Though having asked around apparently they needed the failover when we were on a Adsl line in our main offices, which would go down. But we are on a fiber connection now, which seems very stable. So might just take this out all together.
2 further questions for you if I may.
Why then if we remove that entry would our DNS requests start to work again when we do have problems?
And why would he have set it to this address to a gateway instead of a DNS server? (could this be when the failover to a seperate Adsl line/Ip kicked in it would be needed?)
172.16.8.3 is in private IP address space. I guess that IP address was a DNS server for some/all of the internal VPN-based network. The domain that is pointed to that is obscured in the screenshot, but I guess it is a private domain within the internal network? Without the override, the DNS requests will be forwarded up to the DNS server/s that pfSense is using by default. Maybe those are somehow able to resolve the names. Without more detail of your internal network and where the internal DNS server/s are, it is speculation from me.
If 172.16.8.3 is/was a gateway, presumably that gateway also had a DNS server or forwarder that could help resolve names. Maybe that functionality is no longer enabled on the gateway. Again, a bit of speculation from me.