I'm facing an issue with our remote users, using FortiClient SSLVPN as their remote connection solution.
Mainly, the remote users are using our split-tunnel profile, only tunneling some coperate traffic over the VPN, rest goes out via local internet.
Additional, we have (at least tried) to configure split DNS as well, so that DNS queries for some corporate domains gets resolved by our local DNS server in the Datacenter (over the VPN). All other queries get resolved by local DNS (mainly remote users own ISP).
Now to explain the issue.
We have a public domain, lets call it ABC.COM, with public records registered at a public DNS provider.
That same domain (ABC.COM) also has a few internal (private) records registered at our internal DNS server at the Datacenter. it could be example.ABC.COM.
example.ABC.COM doesn't exist in the public DNS
Now, when remote users establish the split-tunnel VPN connection, in some cases they are able to resolve example.ABC.COM as they should. The internal private records.
But after some time.. and we don't know exactly yet how long, but maybe 30 minutes or so, their application can't resolve it anymore.
My suspicion is, that the WindowsOS (in this case) has tried to resolve the record of example.ABC.COM via it's local DNS (thus not using the split-DNS option).
For the setup: We are running FortiClient 6.2.9 mainly at this point.
The VPN FortiGate runs FortiOS 6.2.10
The configuration settings of the FortiGate is like this:
config vpn ssl settings set reqclientcert enable set servercert "cert-here" set idle-timeout 28800 set auth-timeout 72000 set login-timeout 180 set dtls-hello-timeout 45 set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1" set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1" set port 443 set source-interface "Interface here" set source-address "all" set source-address6 "all" set default-portal "no-access" config authentication-rule edit 2 set groups "our-group" set portal "split-tunnel-portal" next end end
The portal settings are like this:
config vpn ssl web portal edit "split-tunnel-portal" set tunnel-mode enable set forticlient-download disable set auto-connect enable set keep-alive enable set save-password enable set ip-pools "NET-network" set dns-server1 x.x.x.x set dns-server2 y.y.y.y set dns-suffix "our.internal.domain" set host-check custom set host-check-policy "check-windows" "check-mac" config split-dns edit 1 set domains "our.internal.domain,ABC.COM" set dns-server1 x.x.x.x set dns-server2 y.y.y.y next end
For the FortiClient profile config, the following is set:
DNS Cache Service Controll = Restart dnscache service
Prefere SSL VPN DNS = disabled
Executing an NSLOOKUP on a remote users WindowsPC, it can allways resolve the example.ABC.COM
By the way, it's not only for this single record; example.ABC.COM, we experience it for multiple records that has the domain registered in public DNS, but has a few specefic records registered in our private DNS as well.
The SSLVPN tunnel is stable and doesn't get disconnected at all
I've tried to play around with some of the settings for the SSLVPN at the FortiGate and the FortiClient, but without any luck in solving it as this point.
Maybe some of you have? Do you know a tool that can be used to monitor / log the DNS queries a Windows PC performed. I could have wireshark running for some time on a machine -> but maybe there is a better tool out there specific for DNS?
I ran a wireshark capture on a client with the issue. What I have identified is, that the client sends the DNS query towards the DNS server over the SSLVPN tunnel. The DNS server replies back within 0.09 MS with the answer. However the client sends and ICMP message with (destination port unreachable) back to the server, informatin that the answer from the server sendt to the client at the dst. port isn't reachable anymore.
For some reason, the port the client initiates is DNS query form is closed before the reply from the DNS server reaches.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.