Hey everyone, hope you're all having a great day! I'm reaching out about an ongoing DNS resolution problem my team has been facing since early this year. We use Sophos firewalls with IPSEC for remote access via the Sophos Connect software, and our DNS setup includes both a .local and a .com zone linked to our internal Active Directory. Although users can access our website (XX.YY.com) via the IPSEC VPN, it often becomes inaccessible due to DNS issues after they connect. Pinging internal IPs works fine, which rules out routing issues. We've noticed that DNS resolution takes about 15 minutes—or users can run a script to flush the DNS faster since they have local admin access, which isn't ideal but is our current workaround. My tests with Windows 10 and 11 show that the DNS works normally until a specific Windows update is installed (KB5053598). It's pretty frustrating to deal with these tickets, and I'd love to hear if anyone else is having similar experiences or has suggestions for fixes!
4 Answers
Are you using split tunneling? I had a similar problem where the user's home setup conflicted with our internal DNS. The local DHCP assigned an IP that clashed with our DNS server, which caused resolution issues. It's something to check out!
The Sophos client can overwrite local routing tables, so you might be stuck accessing the remote network instead of resolving DNS locally. Maybe you need to adjust your route settings.
Make sure you have your request routing set up properly. I typically add the firewall as a DNS server for VPN connections and route any requests for the .local domain to the internal Domain Controller. It might help resolve those DNS issues.
You might want to capture DNS traffic using Wireshark on one of the devices having issues. It can help pinpoint where the DNS requests are failing, whether it's on the client-side or at your DNS servers. Also consider checking the upstream firewalls for any related captures.
I dealt with a similar issue using SonicWall. I had to create rules to ensure that any internal IPs detected were sent to the internal servers instead of external. With split tunneling, this was crucial. Now that I'm on a zero trust model, our internal DNS handles requests more efficiently, which simplified things a lot!
That's exactly why I avoid using 192.168.x.x for business networks. It just creates unnecessary conflicts!