Split tunnelling & Name resolution weirdness

[wraezor]

Hello, We have been using SSLVPN in tunnel mode with FortiClient for awhile with good success. Intranet and Internet web browsing was successful. Recently, we turned on split-tunnelling so all Internet browsing wouldn' t come through our corporate network. When we did this, we started having some difficulties with name resolution for internal systems. Allow me to explain: Consider the scenario: Laptop at home on DHCP (supplying ISPs DNS) on the wireless network adapter. Launch FortiClient and connects. Fortigate supplies DHCP address (with Internal DNS servers) for ' fortissl' network adapter. The system now has two sets of DNS servers configured. However this happens, it seems the process of connecting the FortiClient tunnel makes the fortissl DNS settings the preferred ones, so name resolution will happen on the Internal DNS server which is what we want. If I launch nslookup, I get the following: Tunnel Disconnected

C:\>nslookup
 Default Server: resolver1.opendns.com
 Address: 208.67.222.222

Tunnel Connected

C:\>nslookup
 Default Server: dc01.abcdefg.com
 Address: 172.16.0.250

So far so good, I guess. We are in a Split DNS environment, so if I attempt to resolve a server name, it will resolve whether the tunnel is connected or not, but with different addresses. Externally it resolves to our wildcard external address, internally, the host record is returned. Tunnel Disconnected

C:\>ping fs01.abcdefg.com
 Pinging fs01.abcdefg.com [72.22.X.X] with 32 bytes of data:

Tunnel Connected

C:\>ping fs01.abcdefg.com
 Pinging fs01.abcdefg.com [172.16.0.133] with 32 bytes of data:

Again so far so good, I guess. The problem is, in my testing over the past few days, it seems like that change is not immediate. If I attempt to ping an internal system immediately (within 2 to 4 seconds) after seeing the FortiClient report " Connected" on the tunnel, it will give me the same results as if it was disconnected every time. Then that DNS entry is cached and will continue to fail until some distant timeout is passed. If I wait and don' t do anything until about 8 or 10 seconds after the connection is established it will be successful pretty much every time. Also, if I issue an ipconfig /flushdns, after its connected, it will work after that. It might sound like a minor problem, but as far as I' m concerned it should just work. I might be totally off base with my troubleshooting, but has anyone seen this before? I don' t understand why it only seems to have showed up after we turned on split tunnelling and why it seems to need some time after it says ' connected' for it to actually work. Thanks in advance for any input.

[ede_pfau]

Well, IMHO the DNS caching is done on the client, by the client' s OS. Having the application (Forticlient) take action on that is an extra, not a necessity. It would be ' nice' if the FortiClient would flush the DNS cache on connection but the work around is quite simple, too. Flushing the cache means higher latency for the client' s applications until the cache is filled up again. I can see why the developer would not want to unconditionally flush the client' s DNS cache on connect. The question is how difficult it would be to deduct from the FC' s configuration that the DNS will change on connect (i.e. split-tunneling is active).

[wraezor]

Thanks for the reply ede. It seems like it does flush the cache during the connection and disconnection process. Isn' t the default TTL for cache entries on Windows like 24 hours? If I were to describe how it behaves based on my observation, it is something like this (though I could be easily mistaken): 1) VPN connection initiated. 2) Tunnel built. 3) Routing table changed. 4) DNS cache cleared. 5) Reporting " Connected" in client. 6) DNS server priority switched (4 to 6 seconds later) If it didn' t clear the cache, it wouldn' t work virtually at all for addresses that had been resolved prior to connecting.

[ede_pfau]

If it didn' t clear the cache, it wouldn' t work virtually at all for addresses that had been resolved prior to connecting

... in the special case when the two alternative DNS resolve the same hostname to different IP addresses. For you, this is common; for the majority of users it is not and they won' t ever notice the switch over. I' ve strung up this to check the DNS cache:

 >ipconfig /displaydns|findstr /C:" Record Name" |findstr /N " :" 

Two thoughts: - DNS caching lifetime does not really matter here - the perceived delay at tunnel-up might well be caused by Windows and the inner workings of it' s TCP/IP stack. As such, hard to influence from your side.

[wraezor]

Fair enough. We' re content to leave it as is. Mostly just an annoyance than anything. It' s our only complaint regarding the SSL VPN. Working great otherwise. Thanks for the dialog.

[fcb]

I face this exact same thing..... the problem for me is that my Exchange server seems to not want to work while other things work and resolve just fine. I would like for ALL DNS requests to use my internal server as the primary and the ISP' s (the one bound to the local NIC) as the secondary. It' s mind numbing. We have a call a day about this and it seems to be Exchaneg mainly. We have our DNS configured properly. We' ve even resorted to adding static entries to the host file of the local machine and although that allows us to ping exchange successfully, it still will not connect. Maybe we could statically assign internal DNS to the Fortinet adapter? I haven' t looked, is this an option? The thing is that at home I use Google DNS 8.8.8.8 and I NEVER have the problem. Any ideas is greatly appreciated.

[rwpatterson]

I don' t use exchange, but I do point my FGT to my internal AD DNS. That DNS then forwards out the door. Just another perspective. By the way, I don' t point my clients to the FGT for DNS, but I DO use FSAE/FSSO.