This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos Connect vs DNS

So i finished all the instructions as posted on page https://community.sophos.com/kb/en-us/133109

Downloaded the client and exported the configuration. Set up the client and finally made a connection.

So far so good. Can ping hosts on the internal network by ip adress, however i can't seem to reach hosts by their name.

I did enter the ip of the DNS server but somehow hosts aren't being resolved.

 

Any thoughts or pointers on this.

 

Thnx, Peter-Paul



This thread was automatically locked due to age.
  • fyi - edited my post before this one prior to seeing your response to include some more details.

    with debug enabled in nslookup it's verified that it's sending all lookups to the 10.0.0.1 dhcp allocated dns server on the physical ethernet adapter rather than the ip of the dns server from the Sophos Connect configuration.  internal servers can still be pinged or accessed fine across the vpn by ip.   Internal hosts resolve ok by nslookup internalhostname (xg lan interfacea ip address here) or nslookup internalhostname.mydomain2.com (xg lan interface ip address here).   The same xg lan interface ip is specified in the vpn >> Sophos Connect configuration xg page.

  • partially answering my own question:  I found that manually setting a metric of 10 on the Sophos TAP adapter (Ethernet 3 in the ipconfig shown above) solves or works around this issue on Windows 10.  Dns lookups then go to the internal dns server specified in the sophos connect policy and are resolving correctly.  This approach was based on https://www.petenetlive.com/KB/Article/0001402

     

    before:

    C:\>netstat -rn
    ===========================================================================
    Interface List
      6...***** ......Intel(R) Ethernet Connection (2) I219-LM
     12...00 ff f7 11 f6 b0 ......Sophos TAP Adapter
      1...........................Software Loopback Interface 1
    ===========================================================================

     

    after:

    C:\>netstat -rn
    ===========================================================================
    Interface List
     12...00 ff f7 11 f6 b0 ......Sophos TAP Adapter
      6...****** ......Intel(R) Ethernet Connection (2) I219-LM
      1...........................Software Loopback Interface 1
    ===========================================================================

  • I have been following this thread for a while as I've had the same issue and not much time to investigate myself. After a few hours of trying to get it to work, I setup SSL VPN again and have been using it ever since.

     

    Upon changing the Metric as you stated, it does fix the issue. I'm not sure it counts as a permanent fix as I believe the client should be doing this automatically just like the SSL VPN Client.

  • Thank you LeetJN and momentum for the data. I will analyze them and see if there is a fix for it in the client. Is it possible that you append a route print output before the connection is enabled and then a route print out after the tunnel is established. This will help.

     

    Thank you again for your feedback.

     

    Ramesh

  • Hello momentum,

     

    Sorry I misunderstood the problem. In fact there is no problem with Sophos Connect client. When you specifically do nslookup it uses the DNS server assigned to the Physical adapter. But when do you Web Browsing or PING by FQDN then windows will broadcast to all the DNS servers and will use the valid reply from the first one. So that is the test I would request you to do and not the nslookup test. Also in nslookuo you can assign a specific DNS server to use and then assign the internal DHCO server and do the test. That will work.

     

    In other words, with Sophos Connect Client 1.2 hostname will be resolved ONLY if it is FQDN. 

     

    I hope this helps,

    Ramesh

  • Hello LeetJN,

     

    I am not sure what problems you ran into with Sophos Connect 1.2. Yes in the current release you cannot resolve just by hostname because the policy does not configure DNS suffix. SSL VPN configuration has a configuration for DNS suffix. For now you need to use FQDN to resolve hostnames.

    I hope this helps.

    Ramesh

  • rmk_2018 said:

    Sorry I misunderstood the problem. In fact there is no problem with Sophos Connect client. When you specifically do nslookup it uses the DNS server assigned to the Physical adapter. But when do you Web Browsing or PING by FQDN then windows will broadcast to all the DNS servers and will use the valid reply from the first one. So that is the test I would request you to do and not the nslookup test. Also in nslookuo you can assign a specific DNS server to use and then assign the internal DHCO server and do the test. That will work.

     

    Was seeing same results from ping with pings going to incorrectly resolved ip returned by the wrong dns server.   ipconfig /flushdns didn't seem to help.   This appeared to resolved after changing the sophos tap adapter metric. 

  • Hello momentum,

    Is this a Windows 10 issue with some configuration that is causing this. We have multiple systems in the lab (Windows 10 and Windos 7) that are used in tests and we do not have this problem. 

     

    Can you run wireshark and capture traffic so we can actually see where the packets are sent to.

     

    Ramesh

  • Hello momentum,

     

    Thank you for all the data you provided. Yes it is a problem and it will be fixed in the next EAP2 that will likely be out by the end of this month.

     

    Regards,
    Ramesh

  • Hello momentum,

     

    Sophos Connect 1.3 is released and it is now available via your firewall via pattern update. You can go to System->Backup & Firmware->Pattern Updates and click Pattern update now to  downloaded in case it is not there already.

     

    Please do let us know how this new version works for you after a week of usage. Looking for feedback from customers for this new release.

     

    Thank you,

    Ramesh