Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

DNS resolution over VPN issue when LLMNR is disabled - Sophos Conect 2.3

I have the same problem as described in the following post:

 RE: LLMNR disabled - DNS resolution no longer works over VPN 

I have now updated to 20v1 MR1 and installed the current Connect Client. Unfortunately, the error is still not fixed with Sophos Connect 2.3. So I have to leave the insecure LLMNR protocol activated on all clients if they want to connect via VPN.

Edited TAGs
[edited by: Raphael Alganes at 3:57 PM (GMT -7) on 10 Jun 2024]
  • Hi  Thank you for reaching out to the Sophos community team. Below are my inputs and suggestions around this:

    LLMNR is used as a fallback mechanism when traditional DNS resolution fails. If a device cannot resolve a hostname through DNS, it may use LLMNR to try and resolve the name locally within the same subnet.

    Based on that I am assuming the DNS resolution that is failing for you is maybe you are referring to internal or local domain traffic! Please correct me if this is not the correct understanding on this or please elaborate DNS is failing for which domains, like internal or external or both of them?

    If this is getting observed with a Windows OS machine then it uses InterfaceMetric value to forward traffic if multiple interfaces are available with DNS settings configured!

    So it is worth checking below and confirming the status to narrow down the situation:

    1)Please keep LLMNR enabled and do not connect Sophos connect on the end machine.

    With this setup, Browse the domain that is failing when you are connected via Sophos connect VPN and capture the Wireshark on interface handling traffic to see/confirm if is it getting resolved via DNS/LLMNR.

    2)Please keep LLMNR disabled and connect Sophos connect on the end machine.

    With this setup, Browse the domain that is failing when you are connected via Sophos connect VPN and capture the Wireshark on the available LAN/WiFi, tunnel adapter to see/confirm whether is it getting resolved via DNS/LLMNR and via which Interface!

    Note: Due to InterfaceMetric value if internal domain queries are getting forwarded to the DNS server of the Tunnel TAP adapter then they are not able to resolve anything in your domain, and instead it will fall back on LLMNR to resolve internal hosts.

    Based on the above comparison if your investigation and findings confirm that it is Sophos Connect that is breaking it then I would suggest an Open Support case to confirm and validate more on this OR If your findings confirm any different results and conclude the issue at your end, please feel free to share those latest finding with us here for community user reference. 


    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support

    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'Verify Answer' link.

  • Hi Vishal_R,

    To clarify, we have been using the Sophos Connect Client for several years for remote access via SSL or IPsec. The connection is established in every case. For security reasons, we recently deactivated LLMNR on the Windows PCs in our domain using GPO. Since then, DNS resolution for these clients through the VPN no longer works for our internal addresses. This only affects traffic through the tunnel; external DNS resolution is not affected. The DNS servers are specified via VPN and can also be reached (in the same subnet as the VPN or in other subnets behind the tunnel). Using nslookup, the names are resolved correctly by all DNS servers. However, if I try to reach an address using a hostname or FQDN, I get the answer that the name cannot be resolved. Access via IP works immediately. To work around the error, I re-enabled LLMNR for the affected PCs and everything works. I cannot imagine that name resolution through the tunnel should take place using LLMNR if DNS fails. The requested addresses are not in the same subnet as the VPN address of the connected client. Every other client (Windows, iOS) that is not in the domain or does not have deactivated LLMNR works. It is exactly the behavior that was requested in the discussion above.


    Steffen Dutschke