Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 34 replies
  • Subscribers 1 subscriber
  • Views 79600 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 in reply to Nardus
    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?
  • 0 in reply to allanak
    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.
  • 0 in reply to jasggomes
    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.
  • 0 in reply to mschimmer
    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.
  • 0 in reply to jasggomes
    Tested with 2.1_rc4 included in V7.305.
  • 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?
  • 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 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 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.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • 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
Unfiltered HTML