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.