Guest User!

You are not Sophos Staff.

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

DNS Problem. Wrong DNS servers

Hi

I'm using the newest Sophos SSL VPN client.
We have the following problem.

We are not able to resolve the internal ressources after connecting with the VPN client.
- We can resolve the external ressources.
- With a nslookup I get the correct server and I can resolve the internal servers.
- With a Ping command I'm not able to resolve the severs. Also not with the FQDN.
- A ipconfig/registerdns and a ipconfig/flushdns will solve the problem

How can I solve this problem globaly for all clients.

Best regards


This thread was automatically locked due to age.
  • Hi, 

    1. what is the client OS

    2. is the client running with admin rights?

    3. utm version #?

    Barry
  • Looks like a wrong binding order of network adapters. The SSL VPN adapter should be first, so that if it's connected it's DNS-settings are used.

    Managing several Sophos UTMs and Sophos XGs both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

    Sometimes I post some useful tips on my blog, see blog.pijnappels.eu/category/sophos/ for Sophos related posts.

  • Hello

    The sophos SSL VPN adapter is already the first adapter.

    UTM version 9.109
    Client: Windows 7 with Admin rights

    Best regards
  • Delete the client and re-install with admin rights.  Also, confirm that 'Remote Access >> Advanced' is completed correctly.

    If that doesn't work, show the client and UTM SSL log lines for a single connection establishment.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hello

    I reinstalled the client with admin rights and also checked the advanced settings on the firewall. Still the same problem.

    Here is the log file from the firewall:


    2014:02:28-13:22:48 fw-rz-01-1 openvpn[5068]: 46.10.97.4:1210 Connection reset, restarting [0]
    2014:02:28-13:22:48 fw-rz-01-1 openvpn[5068]: 46.10.97.4:1210 SIGUSR1[soft,connection-reset] received, client-instance restarting
    2014:02:28-14:29:07 fw-rz-01-1 openvpn[5068]: TCP connection established with [AF_INET]5.145.7.187:55795 (via [AF_INET]156.40.200.131:443)
    2014:02:28-14:29:08 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 TLS: Initial packet from [AF_INET]5.145.7.187:55795 (via [AF_INET]156.40.200.131:443), sid=1fd87049 e3591489
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 VERIFY OK: depth=0, C=ch, L=location, O=company, CN=user
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 VERIFY OK: depth=1, C=ch, L= location, O= company, CN=company ca, emailAddress=servicedesk@company.com
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 VERIFY OK: depth=1, C=ch, L= location, O= company, CN=company ca, emailAddress=servicedesk@company.com
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 VERIFY OK: depth=0, C=ch, L= location, O= company, CN=user
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 PLUGIN_CALL: POST /usr/lib/openvpn/plugins/openvpn-plugin-utm.so/PLUGIN_AUTH_USER_PASS_VERIFY status=2
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 TLS: Username/Password authentication deferred for username 'user' [CN SET]
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
    2014:02:28-14:29:09 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 Data Channel Decrypt: Using 128 bit message hash 'MD5' for HMAC authentication
    2014:02:28-14:29:10 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
    2014:02:28-14:29:10 fw-rz-01-1 openvpn[5068]: 5.145.7.187:55795 [user] Peer Connection Initiated with [AF_INET]5.145.7.187:55795 (via [AF_INET]156.40.200.131:443)
    2014:02:28-14:29:10 fw-rz-01-1 openvpn[5068]: user/5.145.7.187:55795 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/conf.d/user
    2014:02:28-14:29:10 fw-rz-01-1 openvpn[5068]: user/5.145.7.187:55795 MULTI_sva: pool returned IPv4=10.242.2.6, IPv6=(Not enabled)
    2014:02:28-14:29:10 fw-rz-01-1 openvpn[5068]: id="2201" severity="info" sys="SecureNet" sub="vpn" event="Connection started" username="user" variant="ssl" srcip="5.145.7.187" virtual_ip="10.242.2.6"
    2014:02:28-14:29:10 fw-rz-01-1 openvpn[5068]: user/5.145.7.187:55795 PLUGIN_CALL: POST /usr/lib/openvpn/plugins/openvpn-plugin-utm.so/PLUGIN_CLIENT_CONNECT status=0
    2014:02:28-14:29:10 fw-rz-01-1 openvpn[5068]: user/5.145.7.187:55795 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_24e84a36b2af6c3f2e3f24cd7e1fca9d.tmp
    2014:02:28-14:29:10 fw-rz-01-1 openvpn[5068]: user/5.145.7.187:55795 MULTI: Learn: 10.242.2.6 -> user/5.145.7.187:55795
    2014:02:28-14:29:10 fw-rz-01-1 openvpn[5068]: user/5.145.7.187:55795 MULTI: primary virtual IP for user/5.145.7.187:55795: 10.242.2.6
    2014:02:28-14:29:12 fw-rz-01-1 openvpn[5068]: user/5.145.7.187:55795 PUSH: Received control message: 'PUSH_REQUEST'
    2014:02:28-14:29:12 fw-rz-01-1 openvpn[5068]: user/5.145.7.187:55795 send_push_reply(): safe_cap=940
    2014:02:28-14:29:12 fw-rz-01-1 openvpn[5068]: user/5.145.7.187:55795 SENT CONTROL [user]: 'PUSH_REPLY,route 10.242.2.1,topology net30,ping 10,ping-restart 120,route 10.0.10.0 255.255.255.0,route 10.0.99.0 255.255.255.0,route 10.0.1.0 255.255.255.0,dhcp-option DNS 10.0.1.21,dhcp-option DNS 10.0.1.27,dhcp-option DOMAIN company.local,ifconfig 10.242.2.6 10.242.2.5' (status=1)


    Here is the log file from the client:

    Fri Feb 28 14:28:57 2014 OpenVPN 2.3.0 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [IPv6] built on Jun 14 2013
    Fri Feb 28 14:28:57 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
    Fri Feb 28 14:28:57 2014 Need hold release from management interface, waiting...
    Fri Feb 28 14:28:57 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
    Fri Feb 28 14:28:57 2014 MANAGEMENT: CMD 'state on'
    Fri Feb 28 14:28:57 2014 MANAGEMENT: CMD 'log all on'
    Fri Feb 28 14:28:57 2014 MANAGEMENT: CMD 'hold off'
    Fri Feb 28 14:28:57 2014 MANAGEMENT: CMD 'hold release'
    Fri Feb 28 14:29:07 2014 MANAGEMENT: CMD 'username "Auth" "user"'
    Fri Feb 28 14:29:07 2014 MANAGEMENT: CMD 'password [...]'
    Fri Feb 28 14:29:07 2014 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
    Fri Feb 28 14:29:07 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Fri Feb 28 14:29:07 2014 Socket Buffers: R=[8192->8192] S=[64512->64512]
    Fri Feb 28 14:29:07 2014 MANAGEMENT: >STATE:1393594147,RESOLVE,,,
    Fri Feb 28 14:29:07 2014 Attempting to establish TCP connection with [AF_INET]156.40.200.131:443 [nonblock]
    Fri Feb 28 14:29:07 2014 MANAGEMENT: >STATE:1393594147,TCP_CONNECT,,,
    Fri Feb 28 14:29:08 2014 TCP connection established with [AF_INET]156.40.200.131:443
    Fri Feb 28 14:29:08 2014 TCPv4_CLIENT link local: [undef]
    Fri Feb 28 14:29:08 2014 TCPv4_CLIENT link remote: [AF_INET]156.40.200.131:443
    Fri Feb 28 14:29:08 2014 MANAGEMENT: >STATE:1393594148,WAIT,,,
    Fri Feb 28 14:29:08 2014 MANAGEMENT: >STATE:1393594148,AUTH,,,
    Fri Feb 28 14:29:08 2014 TLS: Initial packet from [AF_INET]156.40.200.131:443, sid=5e7fdeb7 686d9567
    Fri Feb 28 14:29:08 2014 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    Fri Feb 28 14:29:09 2014 VERIFY OK: depth=1, C=ch, L=location, O=company, CN=company ca, emailAddress=servicedesk@company.com
    Fri Feb 28 14:29:09 2014 VERIFY X509NAME OK: C=ch, L= location, O= company, CN=fw-rz01, emailAddress=mail@company.com
    Fri Feb 28 14:29:09 2014 VERIFY OK: depth=0, C=ch, L= location, O= company, CN=fw-rz01, emailAddress=mail@company.com
    Fri Feb 28 14:29:10 2014 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
    Fri Feb 28 14:29:10 2014 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication
    Fri Feb 28 14:29:10 2014 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
    Fri Feb 28 14:29:10 2014 Data Channel Decrypt: Using 128 bit message hash 'MD5' for HMAC authentication
    Fri Feb 28 14:29:10 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
    Fri Feb 28 14:29:10 2014 [fw-rz01] Peer Connection Initiated with [AF_INET]156.40.200.131:443
    Fri Feb 28 14:29:11 2014 MANAGEMENT: >STATE:1393594151,GET_CONFIG,,,
    Fri Feb 28 14:29:12 2014 SENT CONTROL [fw-rz01]: 'PUSH_REQUEST' (status=1)
    Fri Feb 28 14:29:12 2014 PUSH: Received control message: 'PUSH_REPLY,route 10.242.2.1,topology net30,ping 10,ping-restart 120,route 10.0.10.0 255.255.255.0,route 10.0.99.0 255.255.255.0,route 10.0.1.0 255.255.255.0,dhcp-option DNS 10.0.1.21,dhcp-option DNS 10.0.1.27,dhcp-option DOMAIN company.local,ifconfig 10.242.2.6 10.242.2.5'
    Fri Feb 28 14:29:12 2014 OPTIONS IMPORT: timers and/or timeouts modified
    Fri Feb 28 14:29:12 2014 OPTIONS IMPORT: --ifconfig/up options modified
    Fri Feb 28 14:29:12 2014 OPTIONS IMPORT: route options modified
    Fri Feb 28 14:29:12 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
    Fri Feb 28 14:29:12 2014 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=11 HWADDR=3c:97:0e:49:b5:a8
    Fri Feb 28 14:29:12 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
    Fri Feb 28 14:29:12 2014 MANAGEMENT: >STATE:1393594152,ASSIGN_IP,,10.242.2.6,
    Fri Feb 28 14:29:12 2014 open_tun, tt->ipv6=0
    Fri Feb 28 14:29:12 2014 TAP-WIN32 device [LAN-Verbindung 3] opened: \.\Global\{979FB952-EE1A-4D97-94E8-32AFC22D7B2A}.tap
    Fri Feb 28 14:29:12 2014 TAP-Windows Driver Version 9.9 
    Fri Feb 28 14:29:12 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.242.2.6/255.255.255.252 on interface {979FB952-EE1A-4D97-94E8-32AFC22D7B2A} [DHCP-serv: 10.242.2.5, lease-time: 31536000]
    Fri Feb 28 14:29:12 2014 Successful ARP Flush on interface [36] {979FB952-EE1A-4D97-94E8-32AFC22D7B2A}
    Fri Feb 28 14:29:16 2014 TEST ROUTES: 5/5 succeeded len=5 ret=1 a=0 u/d=up
    Fri Feb 28 14:29:16 2014 MANAGEMENT: >STATE:1393594156,ADD_ROUTES,,,
    Fri Feb 28 14:29:16 2014 C:\Windows\system32\route.exe ADD 156.40.200.131 MASK 255.255.255.255 192.168.1.1
    Fri Feb 28 14:29:16 2014 Route addition via service succeeded
    Fri Feb 28 14:29:16 2014 C:\Windows\system32\route.exe ADD 10.242.2.1 MASK 255.255.255.255 10.242.2.5
    Fri Feb 28 14:29:16 2014 Route addition via service succeeded
    Fri Feb 28 14:29:16 2014 C:\Windows\system32\route.exe ADD 10.0.10.0 MASK 255.255.255.0 10.242.2.5
    Fri Feb 28 14:29:16 2014 Route addition via service succeeded
    Fri Feb 28 14:29:16 2014 C:\Windows\system32\route.exe ADD 10.0.99.0 MASK 255.255.255.0 10.242.2.5
    Fri Feb 28 14:29:16 2014 Route addition via service succeeded
    Fri Feb 28 14:29:16 2014 C:\Windows\system32\route.exe ADD 10.0.1.0 MASK 255.255.255.0 10.242.2.5
    Fri Feb 28 14:29:16 2014 Route addition via service succeeded
    Fri Feb 28 14:29:16 2014 Initialization Sequence Completed
    Fri Feb 28 14:29:16 2014 MANAGEMENT: >STATE:1393594156,CONNECTED,SUCCESS,10.242.2.6,156.40.200.131
  • Everything worked correctly in those logs.

    It appears that the DNS servers assigned to the client are 10.0.1.21 and 10.0.1.27 - is that correct?  When you say you had to do a /flushdns on the client PC, do you mean before or after disconnecting from the SSL VPN?

    Ping behavior is regulated on the ICMP tab of Firewall, but that doesn't seem to be the issue.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi

    Yes this are the two dns servers assigend to the VPN network card.
    I have to do a /registerdns and a /flushdns after I successfuly connected with the VPN client.
    After this command I can resolve the dns correctly.
  • Before you run those commands, does ipconfig /all show 10.0.1.21 & .27?

    If you're running split DNS and have cached some values that conflict with ones you want via the VPN connection, you will indeed need to /flushdns.  I don't understand why registerdns would be needed though.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob

    It seems the /registerdns comes from this old thread:
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/58/t/53075

    The thread is about an older version of the SSL client. 
    I researched this problem because I have the exact same issue with our new UTM 320. I tested the SSL VPN on a Windows XP and a Windows 7 laptop with the same results. The strange thing is, it doesn't matter if I enable split tunneling or not. I always have this problem. As soon as I do an ipconfig /registerdns after I connect woth the VPN client, I can ping my internal servers by DNS name. If I don't do a ipconfig /registerdns, I can't oing by DNS name, only by IP.
    It soemhow looks like the problem is the VPN client because as soon as I deactivate the firewall rule "VPN Users -> DNS -> any", I see dropped packets to the DNS servers that come from my WLAN connection. But the client should use the DNS servers configured on the UTM. When I do an ipconfig /all, it shows the correct DNS and WINS servers on the Sophos LAN adapter.
    I also added the line 'redirect-gateway def1' to the .ovpn file like suggested here:
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/58/t/54784
    Unfortunately with no success.

    Regards, Fabian
  • Hi, Fabian, and thanks for tracking that down.

    I think that if the registerdns command works, then the flushdns shouldn't be needed.

    On the contrary, if the DNS problem is after disconnecting the VPN client, then only the flushdns should be needed.  If anyone gets a chance to test this hypothesis, I would appreciate some feedback.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA