How to work around an issue with VPN clients and split DNS

Introduction

A couple of years ago I had some good discussions with different people, including a guy from Microsoft Networking Support, about how the name resolution for VPN clients was supposed to work. Everybody seems to agree that when the VPN client connects, we expect that the RRAS adapter will automatically be placed on the top of the adapter list. As you probably know, the adapter order plays an important role in the DNS resolving process because the DNS servers associated with the adapter that has the highest binding order in the adapter list are tried first.

However, in practice we didn’t see that behavior consistently, even if we manually placed the RRAS adapter to the top of the connections list in the Advanced Settings dialog box of the Network and Dial-up Connections tool. Because it didn’t seem to break anything in the configuration I work with, at most I could see a small slow down in name resolving, I didn’t bother to fix that problem.

When I started to publish some internal services and set up a well designed split DNS infrastructure to support it, I immediately got some complaints from some VPN users that some internal services were no longer reachable. It was not difficult to determine that the failing internal services were those defined in the external DNS server too. So, that old VPN name resolving issue was cropping up again and this time it was really breaking things. What was interesting was that only some VPN users were affected although they all use the same configuration, except the type of sharing device connecting their workstation to the cable/dsl modem. Also, take note that a different ISP is used for the VPN clients and the central connection to the ISA server.

Cause

To understand why only some VPN users had problems, let us take a look at the result of the ipconfig and nslookup commands on a working and failing VPN client.

IPCONFIG

  • Windows IP Configuration
Item Working VPN Client Failing VPN Client
Host Name PCSP02 PCEB02
Primary DNS Suffix intranet.splab.net intranet.splab.net
Node Type Hybrid Hybrid
IP Routing Enabled No No
WINS Proxy Enabled No No
DNS Suffix Search List intranet.splab.net
splab.net
intranet.splab.net
splab.net

As you can see in the table above, the Primary DNS Suffix and the DNS Suffix Search List are correctly configured.

  • Ethernet adapter Local Area Connection
Item Working VPN Client Failing VPN Client
Connection-specific DNS Suffix
Description Broadcom NetXtreme Gigabit Ethernet Realtek RTL8139/810x Family Fast Ethernet NIC
Physical Address 00-0B-5D-58-02-C2 00-03-0D-25-BD-12
Dhcp Enabled Yes Yes
Autoconfiguration Enabled Yes Yes
IP Address 192.168.1.101 192.168.2.101
Subnet Mask 255.255.255.0 255.255.255.0
Default Gateway 192.168.1.1 192.168.2.1
DHCP Server 192.168.1.1 192.168.2.1
DNS Servers 195.238.2.22
195.238.2.21
192.168.2.1

As you can see in the table above, no Connection-specific DNS Suffix is configured. This is the standard configuration for any LAN adapter. However, there is a difference in the DNS Servers assigned to the LAN adapter by the DHCP Server in the sharing device. Take note that both users are using the same ISP but they are using a different type of sharing device. On the working VPN client the sharing device assigned the ISP’s DNS servers. On the failing VPN client the sharing device assigned its own IP address as DNS server, meaning this box is acting as a DNS proxy server.

  • PPP adapter VPN Cevi NV
Item Working VPN Client Failing VPN Client
Connection-specific DNS Suffix intranet.splab.net intranet.splab.net
Description WAN (PPP/SLIP) Interface WAN (PPP/SLIP) Interface
Physical Address 00-53-45-00-00-00 00-53-45-00-00-00
Dhcp Enabled No No
IP Address 172.31.1.11 172.31.1.8
Subnet Mask 255.255.255.255 255.255.255.255
Default Gateway 172.31.1.11 172.31.1.8
DNS Servers 172.16.8.14
172.16.10.2
172.31.0.3
172.16.8.14
172.16.10.2
172.31.0.3
Primary WINS Server 172.16.8.14 172.16.8.14
Secondary WINS Server 172.16.10.2 172.16.10.2

As you can see in the table above, the Connection-specific DNS Suffix, DNS Servers and Primary and Secondary WINS Server are all properly assigned to the VPN client. Take note that in the VPN profile the flag Use default gateway on remote network is checked.

NSLOOKUP

  • Without VPN connection
Working VPN Client Failing VPN Client
C:\>nslookup
Default Server:  dnspool042.isp.belgacom.be
Address:  195.238.2.22
C:\>nslookup
Default Server:
Address: 192.168.2.1

As you can see in the table above, the results are as expected. For the working VPN clients an ISP server is returned and for the failing VPN clients the sharing device itself is the DNS server.

  • With VPN connection
Working VPN Client Failing VPN Client
C:\>nslookup
*** Can’t find server name for address 195.238.2.22: Query refused
*** Can’t find server name for address 195.238.2.21: Query refused
Default Server:  adc01.intranet.splab.net
Address:  172.16.8.14
C:\>nslookup
Default Server:
Address: 192.168.2.1

As you can see in the table above, the result is quite interesting. First of all, it should be clear that the PPP (RRAS) adapter is not automatically placed on the top of the adapter list, otherwise one of the DNS servers assigned to the PPP adapter should have responded immediately. Secondly, because the ISP DNS servers assigned to the working VPN client do not accept requests from another ISP (this requests goes through the VPN tunnel and are therefore sourced from the ISA external interface), the DNS resolving falls back to one of the DNS servers assigned to the PPP adapter. Thirdly, because the DNS server assigned to the failing VPN client by the sharing device belongs to a directly connected network, this traffic will never go through the VPN connection.

It should be obvious by now why only some VPN users did have problems. Because the PPP (RRAS) adapter has not the highest binding order in the adapter list, the DNS servers assigned to the PPP adapter are not tried first. Therefore, on the failing VPN clients the DNS server assigned to the LAN adapter is still used. As a consequence, any request for an internal resource (intranet.splab.net) for which a public DNS entry also exists will resolve to the public IP address instead of to the internal IP address. The reason why it worked on the other VPN clients is just by accident. If the ISP used by the VPN clients would have accepted foreign requests to their DNS servers, we would have had the exact same problem.

Workaround

As we already know from the past, manually placing the RRAS adapter to the top of the connections list in the Advanced Settings dialog box of the Network and Dial-up Connections tool does not solve the problem. After some further research I was guided to the Microsoft Knowledge Base article 311218 – Cannot Change the Binding Order for Remote Access Connections. That KB holds the key to a workaround. Nevertheless, keep in mind it is still a defect in the Microsoft OS and as far as I know there are no plans to fix it.

After manually implementing the workaround described in KB311218 on a working and failing VPN client, we tested it again and both VPN clients worked flawlessly. Take note that a reboot was not required and that the registry change was immediately effective. Also, a nslookup on both VPN clients now immediately returned one of the DNS servers assigned to the PPP adapter as shown in the table below:

Working VPN Client Failing VPN Client
C:\>nslookup
Default Server:  zita.intranet.splab.net
Address:  172.31.0.3
C:\>nslookup
Default Server: adc01.intranet.splab.net
Address: 172.16.8.14

After some further testing we found out that implementing KB311218 is not a one time process. Each time something changes to the adapter list, the registry change should be done again. So, it was time to search for a method to automate that process. Because we were also investigating the CMAK (the Connection Manager Administration Kit) to distribute some new VPN settings to the clients, we thought that a script as a pre-connect action should be a good solution. At last we found some useful posts in the ISAserver.org forums and discussion list. The posted code seems all to be based on a script written by Torgeir Bakken, a Microsoft MVP in Scripting and WMI from Porsgrunn Norway.

The original script can be found at http://www.ureader.com/message/89324.aspx and is listed here with just some added comments:

' KB311218 - Cannot Change the Binding Order for Remote Access Connections
' ========================================================================
' VBScript that places the \Device\NdisWanIp entry on the top in the
' registry value Bind (multi-string) that is found under the key
' HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\.
' If the entry already is at the top, no registry update is done.
Const HKLM = &H80000002

sComputer = "." ' use "." for local computer

' Connect to WMI's StdRegProv class
Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" _
& sComputer & "\root\default:StdRegProv")

' Define registry location
sKeyPath = "SYSTEM\CurrentControlSet\Services\Tcpip\Linkage"
sValueName = "Bind"

oReg.GetMultiStringValue HKLM, sKeyPath, sValueName, arValues

arValuesNew = Array()

For i = 0 To UBound(arValues)
  If i = 0 Then
    If LCase(arValues(i)) = "\device\ndiswanip" Then
      ' Entry is already first in the list, no point in continuing
      Exit For
    Else
      ' Put NdisWanIp in the first element in the new array
      ReDim Preserve arValuesNew(0)
      arValuesNew(0) = "\Device\NdisWanIp"
    End If
  End If

  ' Continue adding the rest of the elements to the new array
  If LCase(arValues(i)) <> "\device\ndiswanip" Then
    iCountNew = UBound(arValuesNew) + 1
    ReDim Preserve arValuesNew(iCountNew)
    arValuesNew(iCountNew) = arValues(i)
  End If
Next

' If there are elements to be found in the array, update the
' registry value
If UBound(arValuesNew) > -1 Then
  oReg.SetMultiStringValue HKLM, sKeyPath, sValueName, arValuesNew
End If

Once we implemented  the above script with the help of the CMAK as a pre-connect action in the VPN profile, we did not receive a single complaint about a broken name resolving. As an added benefit, we also incorporated some post-connect actions. First, we properly configured the IE proxy settings for the VPN connection. Next, we enforce some critical updates such as the AntiVirus definitions and the Microsoft Automatic Update to the corporate WSUS server (command %WinDir%\system32\wuauclt.exe /detectnow). At last we enforced the Group Policy (command %WinDir%\system32\gpupdate.exe /force /wait:0).

In the ISA Server 2004 VPN Deployment Kit, chapter 14 Configuring VPN Quarantine there is a complete walkthrough on how to create a Connection Manager Profile. So, we will not repeat it here. However, we will show you some screenshots where you define the above mentioned pre-connect and post-connect actions.

Configure the IE proxy settings for the VPN connection

The ProxyConfig.txt file contains the IE proxy settings for the VPN connection. An example of the content of that file is shown below:

[Automatic Proxy]
AutoProxyEnable=0
AutoConfigScriptEnable=1
AutoConfigScript=http://zita.intranet.splab.net:8080/array.dll?Get.Routing.Script
[Manual Proxy]
ProxyEnable=0

Custom Actions

As an example the details of the pre-connect action Change Binding Order for RAS:

As an example the details of the post-connect action Start Group Policy Update:

It is not within the scope of this article to go further into detail on the CMAK. If you want more information on this subject, please consult the following links:

Conclusion

In this article we examined a name resolving issue with VPN clients and a properly set up split DNS infrastructure. Although this defect in the Microsoft OS will apparently not be fixed unless there is enough customer demand, there are some workarounds possible to mitigate the problem. The workaround discussed in this article is based on the Knowledge Base article 311218, a script written by Torgeir Bakken to automate the required registry change and the use of the CMAK to glue all the different pieces together.

I hope you enjoyed this article and found something in it that you can apply to your own environment. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/m_2002004268/tm.htm and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks!  – Stefaan.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top