Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 34 replies
  • Subscribers 1 subscriber
  • Views 77958 views
  • Users 0 members are here
Options
Suggested
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

jkmichael
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
  • 0
    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.
  • 0 in reply to Blueeyed.1978
    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.
  • 0 in reply to sonay
    Are you having trouble getting the DNS server *delivered* to the client, or is the problem that it gets delivered but just doesn't *work*? 

    In our case, the ASG is set up correctly to hand out the DNS server to VPN clients *and* they get this DNS server when they connect, but they just don't USE it... and for us this only started happening when we upgraded to the 1.3 client. In fact, clients still at 1.2 that haven't upgraded are not seeing the issue at all.
  • 0 in reply to jkmichael
    Hello all

    I don't know, if the mentioned problem ist still here. I solved the DNS / NetBios Cache Problem with following steps below:

    The used SSL VPN Client Supports the use of connect and disconnect scripts.
    I simply created some batchscripts for connect and disconnect, which simply contains following commands in it

    ipconfig /flushdns
    nbtstat -R
    ipconfig /registerdns

    This will flush DNS and NetBios Caches and use the newly delivered DNS. But you have to rename the default profilename "UserX@domainy.zzz" and *ovpn filename to a name without special characters as "@" to get you batchfiles to work.

    Thiy way also can be used to map network drives and do other nice things ;o))

    Works fine for me.

    Run Connect/Disconnect/Preconnect Scripts
    -----------------------------------------

    There are three diffrent scripts that OpenVPN GUI can execute to help with diffrent tasks like mapping network drives.

    Preconnect  If a file named "***_pre.bat" exist in the config folder
                where *** is the same as your OpenVPN config file name,
                this will be executed BEFORE the OpenVPN tunnel is established.

    Connect     If a file named "***_up.bat" exist in the config folder
                where *** is the same as your OpenVPN config file name,
                this will be executed AFTER the OpenVPN tunnel is established.

    Disconnect  If a file named "***_down.bat" exist in the config folder
                where *** is the same as your OpenVPN config file name,
                this will be executed BEFORE the OpenVPN tunnel is closed.
    "
    Base information found under following link:
    http://openvpn.se/install.txt

    [H]
  • 0 in reply to Sascha Paris
    Great info Sascha.  Lately we've encountered some VPN connection issues and will try your scripts / batch files.  Thanks for posting.

    Users with problems might also try using a later version of the OpenVPN client (which is what Astaro uses) at the OpenVPN website link below.  It sometimes helps.  They're about to release v.2.1.

    Welcome to OpenVPN

    >
  • 0 in reply to eganders_01
    According to my log file I'm using client 2.1_rc4 and still having the problem.  I haven't tried the scripts that Sascha has put out though.
  • 0 in reply to abens
    Hi to All.

    I'm also having this issue and currently we have a support case open at support US for this. it has been taken to Development team as far as I know.
    So far no one ever mentioned the use of scripts.

    My problem is also with the AD users using SSL VPN.
    Our solution was, for now, to create all users that use SSL locally on the ASG and put an updated hosts file on every laptop. So far so good.

    Client version is in fact 2.1.rc4

    Best regards

    Jorge Gomes
    =======================

    PS - Sascha, I've tried your scripts, but still can't resolve my DNS names [:(]

    The commands inside each script are :
    ipconfig /flushdns
    nbtstat -R
    ipconfig /registerdns

    I think the last one can't make much sense butI used also.
Reply
  • 0 in reply to abens
    Hi to All.

    I'm also having this issue and currently we have a support case open at support US for this. it has been taken to Development team as far as I know.
    So far no one ever mentioned the use of scripts.

    My problem is also with the AD users using SSL VPN.
    Our solution was, for now, to create all users that use SSL locally on the ASG and put an updated hosts file on every laptop. So far so good.

    Client version is in fact 2.1.rc4

    Best regards

    Jorge Gomes
    =======================

    PS - Sascha, I've tried your scripts, but still can't resolve my DNS names [:(]

    The commands inside each script are :
    ipconfig /flushdns
    nbtstat -R
    ipconfig /registerdns

    I think the last one can't make much sense butI used also.
Children
  • 0 in reply to jasggomes
    I have the same issue, I us the VPN from work and my DNS servers do not know anything about resolving my work inviroment and only can resolve internet and my home network. I think the issue is that even though you get asigned the home DNS on the SSL adaptor the main adaptor still has the work DNS servers and the XP client will use any one of them that answers first. This would explane the users that said his DNS resalution was spoty. I resolved my issues with a Host file for my home systems and removed my Home DNS. It would seem that if I had the mind to I could define stub zones on my home DNS servers with all my work domains and point them to my work Roots but this is more work for me than just managing my host file.
  • 0 in reply to MarkMurphy
    I'm seeing a problem where the SSL VPN 1.3 clients will receive the DNS server address and use that DNS server for a period of time, then "forget" the server address and stop resolving, even though the IP address is correct.

    Another issue is that access to file shares is horribly slow, I mean painfully slow.  If I adjust the packet filter so the user can access the same file share without the SSL VPN, access is lighting fast.  I wouldn't think that the encryption would be that massive of a hit, seconds versus minutes, literally.
  • 0 in reply to troy.murray
    I'm seeing a problem where the SSL VPN 1.3 clients will receive the DNS server address and use that DNS server for a period of time, then "forget" the server address and stop resolving, even though the IP address is correct.

    Another issue is that access to file shares is horribly slow, I mean painfully slow.  If I adjust the packet filter so the user can access the same file share without the SSL VPN, access is lighting fast.  I wouldn't think that the encryption would be that massive of a hit, seconds versus minutes, literally.


    Hi Troy, just to say, unfortunately that we also have the same problem. Still waiting for the support to give us a solution for this. We also tried the openVPN client RC14 but the problem remains.

    I just hope that the solution cams quickly.

    Regards

    JG
  • 0 in reply to jasggomes
    JG,

    I'm of the opinion that this is totally a SSL VPN client issue, here's why, on my Mac I use the Viscosity OpenVPN client with the configuration file from my Astaro and would experience the same "DNS forgetting" that my Windows counterparts were having.  The Viscosity OpenVPN client has an option for "Alternate DNS support" which causes Viscosity to use a different approach. Instead of completely replacing the DNS servers, it adds your VPN servers to Mac OS X's DNS system, and gives them a higher priority. This is the nicest way of setting the DNS servers, especially if you use multiple OpenVPN connections simultaneously. While it in theory should work perfectly, some applications that use older techniques to identify the DNS server/s (such as VMWare) may fail to use the correct DNS server.

    I cannot find this type of option in the Astaro SSL VPN client.

    I had one of my Windows users remove the Astaro SSL VPN client software, then install the OpenVPN 2.1_rc15 package with GUI and try it.  The "DNS forgetting" happens less often, however the slowness remains.
  • 0 in reply to troy.murray
    Troy, you're 100% correct on your reply, its an openVPN client issue.

    Let's hope that the guys at Astaro support can develop a solution, I have my client on my back because of this, all my laptops had to have a local hosts file configured with the resources that they mostly use.

    Regards.
  • 0 in reply to jasggomes
    Hello everybody,

    solved problems for me. But i have about 400 clients. There have to be another solution.

    Greets
    Stephan
  • 0 in reply to StephanG
    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.
  • 0 in reply to Scott_Klassen
    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
  • 0 in reply to jasggomes
    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
  • 0 in reply to mschimmer
    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?