DNS Forwarder - Domain Override
-
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.
Thanks
-
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[39574]: 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.
-
172.16.8.3@@192.168.55.3For 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". -
Hi Phil,
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.