Skip to main content
hpadm
hpadm
New Member
September 5, 2022
Question

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

  • September 5, 2022
  • 4 replies
  • 17586 views

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.

    4 replies

    sw2090
    SuperUser
    sw2090
    SuperUser
    September 5, 2022

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

    pminarik
    Staff
    pminarik
    Staff
    September 5, 2022

    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.

    pminarik_0-1662387807064.png

    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
    hpadmAuthor
    New Member
    September 6, 2022

    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
    hpadmAuthor
    New Member
    September 26, 2022

    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
    Staff
    pminarik
    Staff
    September 27, 2022

    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.8split tunneling - tooltip from 6.4.8

    split tunneling - 7.0 GUIsplit tunneling - 7.0 GUI

     

    hpadm
    hpadmAuthor
    New Member
    September 28, 2022

    -duplicate-

    Terms & ConditionsAccessibility statement