Description

In some scenarios it can be a big advantage to use split-tunneling in combination with DNS Suffixes in order to make it easier to access internal systems without having to type in the entire FQDN (Fully-Qualified-Domain-Name). Split-tunneling is used to avoid the client making queries towards the Internet through the VPN interface and only use the VPN interface when accessing internal resources in e.g. the corporate network IP range.

Configuring split-tunneling on the OneConnect server in cOS Core could look like this if we mainly look at the DNS and routing option sections:

Flow example

If we take the above image/configuration as an example. If we connect with the OneConnect client and then open a browser and type in “myserver”, it would automatically add “myserver.example.com” to the query and send the query to the “if1_dns1” (Corporate DNS) as defined on the OneConnect server interface. The functionality is that the defined DNS server (if1_dns1) would then resolve “myserver.example.com” with an IP address that is within the “RemoteNetwork” network range. The request is sent through the VPN tunnel interface and to the target server beyond the VPN tunnel.

That is how it “should” work under normal conditions and is how it works on macOS, iOS and Android.

The problem

If we take the setup in the above image as the example scenario. If we in this scenario type in “www.clavister.com”, it would NOT query the “if1_dns1” (Corporate DNS) server but rather the interface DNS (ISP-DNS) server configured on the client machine. This will result in a type of DNS leakage where the user get the impression that Windows sometimes consult the DNS server beyond the VPN interface and at other times consult the DNS server configured on the client machine interface (ISP-DNS).

To summarize, the problem triggers only if the following is true:

• DNS suffix is used
• Split tunneling is used
• The client is Windows based

If DNS suffix is not used, all DNS queries would be sent through the VPN tunnel. If split tunneling is not used, all DNS queries would be sent through the VPN tunnel. It is the combination that triggers the problem.

Q & A

Is this a new problem?

No, and it’s probably wrong to call it a “problem” as it’s a design decision made by Microsoft™. An inquiry to MS yielded the following feedback:

Question:

Is this expected behavior when using split tunnel together with DNS suffix? If no, how should it be setup and work?

Microsoft:

I discussed your question with the VPN development team, and we can confirm that this is an expected behavior. When connected to a VPN with Split Tunneling enabled (Gateway disabled), DNS resolution always uses the LAN DNS servers, ignoring the DNS servers and the DNS Suffix set on the VPN. UWP VPN relies on the NRPT table to configure DNS servers, particularly for DNS servers over the VPN tunnel. You can list all the NRPT policies with “netsh name show pol”. In your example, if ‘www.clavister.com’ is not covered by any NRPT policy, the DNS query won’t be sent to the DNS server configured by VPN tunnel. This is by design.

Is the problem in Clavister products, Windows or both?

It is a “problem” in Microsoft Windows based on their design decision regarding DNS queries in this scenario, see above answer.

Will this be changed to make it work in the future?

No, not unless Microsoft changes their core design on how DNS queries work together with e.g. VPN tunnels.

Related articles