DNS problem with SSL VPN in tunnel mode

[horinius]

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?

[ede_pfau]

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]

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]

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]

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]

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]

> 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]

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]

> 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]

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.