Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 34 replies
  • Subscribers 1 subscriber
  • Views 77956 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.
  • 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.
  • 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