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

New SSLVPN client DNS problems

I've been having a chronic issue ever since upgrading the SSLVPN client from v1.2 (which worked great) to the newer 1.3 that is included with 7.1xx. The issue is that the VPN connects perfectly fine, and I can ping all internal hosts just fine, but *DNS* is broken. The client shows that it got the internal DNS server (which pings just fine), but DNS names are *not* being sent to this internal DNS server provided to the SSL adapter. Instead, the DNS the machine is already using (in this case, an ISP DNS) is used instead... thus I can't resolve any internal names, even though I can connect to anything across the VPN by IP address!

Here are some facts:

- ipconfig /all shows that the SSLVPN adapter gets the correct internal DNS server delivered to it.
- pinging the internal DNS works, and all hosts across the VPN can be contacted by IP address.
- while connected to VPN, the client does NOT use the internal DNS like it used to.
- This ONLY started happening with the 1.3 SSLVPN client. 
- About one out of every four attempts the client *will* use the internal DNS like it should, but it seems random.
- Sometimes doing ipconfig /renew *while* connected to VPN will instantly fix the problem and the client starts using the internal DNS.
- Packet filter log does not show any DNS packets being generated by the VPN client being blocked. (I thought perhaps there was a problem with the auto-packet-filter feature of the SSLVPN, but this doesn't seem to be the case)
- This is happening on Windows XP SP2 + latest patches. Haven't tested on any other OS.

I am at a loss as to what is wrong, other than guess that the newer 1.3 client is simply broken in some way regarding DNS. 

Any suggestions?


This thread was automatically locked due to age.
Parents
  • Did you make sure to add your DNS servers in the Advanced tab of the Remote Access section?  I think that is where it is at...I am not looking at my firewall at the moment.  In the Advanced tab you have to add the DNS servers in.  You will also see entries in this same location for WINS servers etc.
  • We have the same problem with our ASG320 Version 7.104 and SSL VPN Client 1.3.
    Our workaround at the moment is to set DNS Server under Astaro SSl VPN adapter manually.
  • Maybe related, maybe not. I've noticed that my VPN clients can't resolve CNAME records from the internal DNS servers (which are listed in WebAdmin) anymore. I use these to give an easy name to punch into a browser for various "web" based sites and applications within the company LAN. I can connect by machine name (A record) and by IP Address, just not by the CNAMES. Is it possible that this is related to the DNS patch Microsoft put out a few months ago to randomize the port used?
     
    I now know what is happening, just not why. I fired up WireShark and began sniffing the TAP interface. Apparently whenever I try going to some resource where the name is registered as a CNAME (alias), such as http://intranet, for whatever reason, DNS resolution isn't even attempted. The only resolution tried is NBNS (NetBIOS/WINS). No WINS records for aliases, so the resolution fails.
     
    I added static records to my internal WINS servers, and resolution of these names bagan working correctly. Very strange that the OpenVPN isn't even attempting DNS resolution, even with WINS servers removed from the VPN configuration is WebAdmin.
     
    We actually have a secondary VPN access, through a Cisco device. DNS resolution for CNAME records works fine over that connection, so this is definately an OpenVPN/Astaro problem happening here.
  • Hi, I still have a open support for this, and so far no resolution whatsoever.

    I'm going to try test it on the beta, but I'm being flooded with work and i still couldn't do it.

    Regards
  • Hello,
    i have the same problem here and fixed it as follows:

    Added to the client.openvpv-default following entries
    #Route
    route-method exe
    route-delay 2

    works fine for me.
    You need to update the clients
  • Hello,
    i have the same problem here and fixed it as follows:

    Added to the client.openvpv-default following entries
    #Route
    route-method exe
    route-delay 2

    works fine for me.
    You need to update the clients


    Hi, on which client did you test it?
  • Tested with 2.1_rc4 included in V7.305.
  • I reopened my support case, since they close it without any knowledge of mine and without any solution.

    Let's see what happens this time.

    We are using the latest VPN client given from our ASG 320.

    I'm going to test your idea, I'll post back the findings.

    Regards.
  • I think I'll bump this to the top. I have a client evaluating an ASG appliance with the exact same issue and they're not happy...sometimes DNS works, other times it does not.
  • Check your DNS ACL for your SSL-VPN IP range. Your SSL-VPN range should have access on the DNS to query the DNS server.
  • Firewall rules to DNS servers would not cause intermittent name resolution. ACLs are definitely not the problem. I believe the problem is with the OpenVPN client and setting DNS priority (or lack thereof). Connect once or twice, no resolution. Reconnect and it works fine.

    To simplify:
    1. User connects to VPN
    2. User pings a resource by name...can't resolve
    3. Ping by IP...works fine
    4. Disconnect

    --- Rinse, repeat...different results ---

    1. Reconnect to VPN just after disconnecting
    2. ping by name...works

    How does this make sense?
  • Hello to all and sorry for the delay, the support found a solution for my case, and so far it's working.

    The solution is to issue a 'ipconfig /registerdns' after the process of VPN logon, you can test it manually but it can be done automatically.

    There is some scripts on this thread that can do that but the people at the support done some alterations on the config files at the ASG

    This is the solution, given to me by ASG support, I hope not doing nothing wrong on posting it here, if so please remove it at once and PM me.

    ----------------------------------------------------------------
    to add the change to all config files which are downloadable over the enduser
    portal please edit the file client.ovpn-default who is located at
    /var/openvpn/client. Add following lines to the end of the file:

    #dns workarround
    push "ipconfig/registerdns"

    If you download now a configuration over the user portal this line should be
    included at the .ovpn file located at
    c.\programs\astaro_ssl_client\config\connection\.ovpn
    ------------------------------------------------------------------------------
    Again, this is not my credit, its from the helpful support guy that does not stopped until we find something we could work on.

    I hope this can help all of us with this annoying problem.

    Best regards.
Reply
  • Hello to all and sorry for the delay, the support found a solution for my case, and so far it's working.

    The solution is to issue a 'ipconfig /registerdns' after the process of VPN logon, you can test it manually but it can be done automatically.

    There is some scripts on this thread that can do that but the people at the support done some alterations on the config files at the ASG

    This is the solution, given to me by ASG support, I hope not doing nothing wrong on posting it here, if so please remove it at once and PM me.

    ----------------------------------------------------------------
    to add the change to all config files which are downloadable over the enduser
    portal please edit the file client.ovpn-default who is located at
    /var/openvpn/client. Add following lines to the end of the file:

    #dns workarround
    push "ipconfig/registerdns"

    If you download now a configuration over the user portal this line should be
    included at the .ovpn file located at
    c.\programs\astaro_ssl_client\config\connection\.ovpn
    ------------------------------------------------------------------------------
    Again, this is not my credit, its from the helpful support guy that does not stopped until we find something we could work on.

    I hope this can help all of us with this annoying problem.

    Best regards.
Children
No Data