Dealing with DNS server and DNS suffix being set by third party FortiGate server

[hpadm]

We are required to access a third party service via a FortiClient VPN connection to their FortiGate-managed network. Their configuration is (unintentionally) hostile to our AD-managed LAN, pushing things like a default route that is blackholed, dns servers that either don't respond or spoof answers, interface metric 1 to give them priority over ours, and dns suffixes that override our primary suffix. This causes our workstations to lose contact with AD, unable to resolve server and printer names, and eventually drop out of the domain.

In the past I have been able to set countermeasures against most of those using a combination of FortiClient XML config settings and windows policies. The third party service doesn't use or need DNS names, so the easiest way was to prevent things from being set. But with the current version, I have trouble with the following:

1. DNS servers are being set on the SSL VPN adapter interface. Together with Metric=1, this causes the dns servers to become the 'most preferred' / default, and all queries will first go to them. Not only does this result in an information leak, the servers can also do spoofing or have a catch-all rule that breaks everything. In older FC versions that used a RAS adapter, manually set DNS servers would not get overwritten; now they do, so this method of blocking doesn't work anymore. If the vpn interface had a higher (automatic) metric than the physical interface, that could at least be a partial fix. The only other idea I have is to firewall the servers off and accept the 2-second query timeouts (plus a 20-second vpn connection delay).

2. Primary DNS suffix is being set on all interfaces, including the physical one, and it's being placed at the top, overriding the suffix for our AD domain. AD requires clients to be able to resolve the short name for the domain and its servers, so this immediately breaks AD, in addition to not being able to resolve printers, desktop shortcuts, shared drives, etc. Interfaces have a "Connection-specific dns suffix" setting, so maybe FortiClient should be using that instead of editing the global suffix search list. Or maybe it should be adding it to the end of the list. There's also a flaw with this approach, where if the workstation bluescreens or loses power, the vpn suffix gets stuck there and persists.

This third party network's configuration has been a problem for at least 6 years, with no improvement in sight. This despite them having many other enterprise clients. I don't have any hopes in them developing a solution on their own, and I can only guess how their configuration looks like. The other approach would be to deal with it clientside. FortiClient already contains a bunch of vpn options to control dns behavior, so maybe more could be added to deal with this.

EDIT: I have been able to lock down the global suffix search list via a specific Group Policy setting.

EDIT: Using the <on_connect> script it is possible to 'roll back' the changes via 'wmic nicconfig', but it requires admnistrator privileges.

[sw2090]

Probably you could set dns-server-override to disabled on the vpn interface to prevent it from adopting dns servers?

[pminarik]

A tip you can share with your 3rd party FortiGate's admins.

1, The general SSL-VPN settings can be set to not override DNS and leave it alone.

The same can be done with domain suffix. (CLI-only)

2, Individual SSL-VPN portals can be configured to override the general setting's DNS IPs and domain suffix lists. (CLI only)

1 + 2 = The third-party admin could set things up so that their own people receive specific portal(s) that use specific DNS IPs and domain suffixes, while other parties (such as you) are set to match a portal that does not override either of these.

[hpadm]

Thanks for the tip. I assume the service is providing the suffix and dns servers so that clients connecting would have a full experience. And/or, as you suggest, they are using a single portal for both their employees and customers. So in that regard, that part is fine, it could even be useful to use dns names for servers for flexibility. The issue stems from poor control of dns in 'split tunneling' mode.

It seems that a low Metric is all it takes for the vpn dns servers to take over. Further making things worse is the altering of the global suffix search list. If FortiClient would instead just define a connection-specific suffix for its interface, then in a default windows configuration, the suffix search list would be generated automatically and sorted by Metric. FortiClient's aggressive approach ensures that the vpn goes first. It also breaks things by preventing the primary and connection-specific suffix of the physical interface from being applied (and it does not fill them into the list when it toggles the mode from automatic to manual).

I have done the following adjustments:

1. Set Metric=1 on the physical interface to fix the priority. Hopefully if two interfaces have the same metric, the order will be stable and the physical one will be listed first.

2. Set a suffix search list via Group Policy. This prevents it from being overwritten. Unfortunately it is not possible to enforce automatic mode, only manual mode, so even if a connection-specific suffix were set, it wouldn't have an effect. This prevents me from resolving FQDNs in the vpn network that also exist on the public internet, but fortunately they also have a secondary local suffix.

[hpadm]

After some testing, I believe I have some observations and suggestions I can offer to the developers to better support the abovementioned scenario. But first, I need to ask about 'split tunneling' mode. On a technical level, what does it do, exactly? I've read that it is used when the client needs to retain access to its existing network, and only use the vpn for certain specific things - which is exactly what is happening in my case. But the documentation does not state what it actually does. Is it a trivial toggle that just changes the client's default gateway and nothing else? Or does it also affect how the client's interface priority, dns server priority, domain suffix priority, etc? Can I find out on the client side if the server is marking the vpn link as split tunnel or not?

[pminarik]

Split tunneling deals with routing on the client machine.  

"Full tunnel" will push all of the clients outgoing traffic through the tunnel.  

"Split tunneling" will only push "interesting" traffic through the tunnel. This is done based on the routing table, so feel free to check your client machine's routing table when you are connected to SSL-VPN with split routing enabled.

Regarding documentation, I have to disagree. The GUI provides pretty self-explanatory description of this functionality. Not sure what else you would like to add to it.

split tunneling - tooltip from 6.4.8

split tunneling - 7.0 GUI

[hpadm]

-duplicate-

[hpadm]

Thank you for the clarification. I do not have administrative access to the Fortigate host nor can I view its configuration; I can only connect via ssl vpn as an user/customer. I tried looking up info on the fortinet website (there's a section for split tunneling), in the forticlient administrative guide (only reference is in ipsec, with no explanation), and in the fortigate administrative guide (something must have broke because back then I only got a few matches). From the above description, it seems split tunneling is unrelated to DNS and seems to directly correlate with the 'traffic_control' forticlient config section. (Can I see a dump of the server's settings somewhere in the logs?)

What I did notice was a section called "Split DNS". It seems to be directly mentioning the behavior that I desire ("only resolve hosts from these specified domains via the vpn's dns servers"). However, it was too technical for me and I was not able to deduce the full extent of the effects it should have on the client host, or the means in which it operates. I also can't tell if Forticlient can actually do that (via some kind of kernel driver?) because windows does not have that feature, or if it's something that is assumed to be happening and was never actually checked on a real pc. Unfortunately, I only have the clientside view of the situation and I have zero experience operating FortiGate, so the best I can do is report behavior that doesn't seem right or is causing issues, and hope that more experienced people can clue me in.

I have done another detailed re-test. I have submitted the results to the business partner providing the vpn service, however I don't know if that'll go anywhere. I include my findings here as well. The main concerns are:

1. Local short names, local FQDNs, as well as internet host names are being sent to an untrusted third party for dns resolution, instead of / before consulting our AD DNS. This is an internal information leak and allows for business espionage by monitoring dns queries. It also allows for connection hijacking via DNS spoofing, and even though the third party is not malicious, an intruder to their network could be. So now all of their customers' network security is tied to their security.
2. Forticlient installs a global suffix search list. If one is already present, its entries get pushed down. If instead the host is in the default windows state where the list is automatically determined from the Primary and Connection-Specific suffixes, then those get stomped over by the new global search list and ignored, and the host is no longer able to resolve short names in its own domain. This seems like a glaring bug in Forticlient; shouldn't it manually add the formerly automatic entries to the list?
3. If the third party has a misconfigured DNS server with a wildcard catch-all rule, then name resolution will always break once it reaches that point. And since the third party's suffixes are in front of ours (if ours is in there at all), none of our LAN short names nor FQDNs will ever resolve properly.
4. Windows decides the DNS server query order solely based on the interface metric. Forticlient sets metric=1 on its vpn interface, ensuring that the vpn's dns servers will always be queried first for everything - unless another interface also sets its metric to 1. There is no xml option to make it not do this. Strangely, even if the suffix of the FQDN to be resolved matches the connection-specific suffix of an interface, Windows will not use that as a hint for which DNS server to use, and will keep using the rigid metric-based order.
5. Windows 10 sends parallel requests to dns servers on all interfaces, and chooses the first positive reply based on metric order. This includes LAN short names, LAN FQDNs, as well as internet hostnames. This renders any fixes to the above issues moot. This behavior can be disabled via a group policy setting, and should be done as the first thing in this sort of scenario.