Skip to main content
horinius
horinius
New Member
February 18, 2011
Question

DNS problem with SSL VPN in tunnel mode

  • February 18, 2011
  • 10 replies
  • 7946 views
Since we have SSL VPN (in tunnel mode) set up in our FGT80C (version 4.1.4) on June 2010 by our vendor, we' ve been noticing a strange DNS problem. No, it' s not about the DNS suffix problem, but a real DNS problem. We noticed that sometimes host names are not resolved at all, eg ping 1.2.3.4 has replies while ping name.mydomain.com has no reply and this is the case whatever name is used. I was pretty sure DNS request didn' t get to our internal DNS server but it is totally reachable because ping dns_ip_address has replies But I don' t know how to " follow" DNS requests to see where they are actually sent to, so I can' t confirm on this point. What' s annoying with this problem is that it' s not reproducible. At least, I' m unable to find the pattern how to reproduce it at ease. But I have a little trail (or maybe just some unfortunate co-incidence?): when I reboot the FGT and I immediately connect to VPN, 4 out of 5 times I come across this problem. But if I use another computer to connect another VPN (the first VPN tunnel is still maintained), the 2nd computer has no DNS problem. So all I can do to my end-users is to tell them to reconnect VPN again and again until that works... :( Has anyone come across this problem? Known bug? Or bad config?

    10 replies

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    February 18, 2011
    No, this is not normal. Have a look at what the DNS resolver does (assuming that your FG is the one and only recursive DNS in your network): 
     on the command line, type  diag deb ena  diag deb cons time ena  diag deb app dns -1    stop with:  diag deb dis  diag deb app dns 0
    horinius
    horiniusAuthor
    New Member
    February 18, 2011
    No, our FGT doesn' t have the role of DNS server. We have internal, independent AD-integrated DNS servers (based on Windows Server 2008 but this should not change anything).
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    February 18, 2011
    Still, you can use the debug commands to follow the dnsproxy on the FG while it' s resolving its own DNS requests, e.g. from " exe ping www.whatever.com" on the CLI. For each (new, uncached) DNS request there should be one request going to the internal DNS on your LAN.
    horinius
    horiniusAuthor
    New Member
    February 18, 2011
    Let me see if I understand it. The group of commands " diag deb ena ..." is to be entered in the CLI of FGT. And the " exe ping www.whatever.com" is to be entered in the (VPN client) computer, right?
    Maik
    Maik
    New Member
    February 18, 2011
    Hi Horinius Just requesting some more background infos: Are Windows 7 and Vista clients affected, while XP works? Is Split Tunneling enabled? Is the problem gone when you disable/turn off the DNS Client service? Does the name resolve with " nslookup" while " ping" to the same name fails? regards Maik
    horinius
    horiniusAuthor
    New Member
    February 18, 2011
    > Are Windows 7 and Vista clients affected, while XP works? I did the test at home and I only had XP Pro SP3 at that time. So, the partial answer is " problem occurs with XP" I had two computers at home and both had this problem. > Is Split Tunneling enabled? Yes. But if I remembered it correctly, we also had this problem without tunnel split. But it' s hard to confirm as the FGT is now being used 24/7: shutting it down for test is a big problem to my company. > Is the problem gone when you disable/turn off the DNS Client service? I don' t know. I' ve never gone in that direction. Are you thinking about WINS? In case you' re asking: No, I don' t put WINS server in VPN config. Because as I understand it, order of name resolution is (DNS cache, hosts file, DNS, WINS) (cf http://support.microsoft.com/kb/172218). Since I always flush DNS cache before every test, and hosts files contain no host name other than localhost, that means the problem encountered can only be due to DNS. > Does the name resolve with " nslookup" while " ping" to the same name fails? No, nslookup didn' t work either.
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    February 18, 2011
    Yes, these debug commands are entered in the CLI, either from the Console App or from an ssh terminal client (prefered). You can have multiple ssh logins active at one time, so you can check the debug output in one window and enter the ping command in the other. The whole point of trying to ping is that you do it from the CLI of the FG itself - not from a client. This way, you test the name resolution of the FG which is used for e.g. SSL VPN. Your SSL policy supports DNS, of course, among other services, right?
    horinius
    horiniusAuthor
    New Member
    February 21, 2011
    > Your SSL policy supports DNS, of course, among other services, right? I suppose you mean the policy from ssl.root as source interface to internal target interface, right? I do have this policy and its " service" is set to ANY while " action" is set to ACCEPT. But that should not be the cause because the problem is not always present. It is there sometimes. OK, I' ll try the debug command next time when I reboot the firewall.
    atong888999
    atong888999
    New Member
    April 25, 2011
    I have same problem, My fortigate is 310B with firmware 4.0 MR3, Client OS: XP/Win7. If the Split Tunneling is enabled, the client often can not resolved intranet dns, user have to logout and login many times and check if the dns is resotred to normal. i found the client has two dns server when the ssl vpn is connected, one is for internet, another is for intranet (ssl-vpn), and client use the internet dns server somtimes, and use the intranet dns server somtimes, i can get the correct ip if use the command " nslookup intranethostname" ; but can not get the correct ip if use the command " ping intranethostname" sometimes, it return " Ping request could not find host intranethostname.com. Please check the name and try again" . If disable the Split Tunneling, because the client can not connect to internet dns server, it has to use the intranet dns server, and all dns can be resolved successfully.
    atong888999
    atong888999
    New Member
    June 17, 2011
    top
    Terms & ConditionsAccessibility statement