Untangle OpenVPN client stops resolving FQDNs in Windows 7?

We use the OpenVPN module in the Untangle Open Source Network Gateway for remote access at our school district.   Everything had been working flawlessly for over a year until suddenly right before I was set to leave for a two day conference, I turned on my Windows 7 RC1 Acer Aspire One netbook, fired up the OpenVPN GUI client and then proceeded to fail at connecting to my remote clients using RDP.    I immediately checked my desktop Windows 7 RC1 install and found the same problem.  Long story short, somehow I had lost the ability to resolve my hostnames  to their correct private IP addresses while connected to the VPN.  The work around for my trip was to connect using IP addresses, which I duly noted before leaving.

Upon my return I decided to troubleshoot the problem.  I was able to rule out a server side issue because 1) no settings had changed since the last time it worked and 2) my Hackintosh OS X desktop system running the OpenVPN client Viscosity worked just fine.  So to rule out my netbook as the culprit, I dusted off my old Dell Inspiron 6400 laptop, which is also running Windows 7 RC1, and tried the OpenVPN GUI client on it.  I got the same frustrating thing, the VPN client connected fine, I just couldn’t resolve my internal DNS names correctly.  I was wondering if this was a problem with the OpenVPN client I was running (2.1rc15) or what else could have possibly changed on both these systems to have this affect.  I decided to try my last instance of Windows 7 RC1 and so fired up Virtual Box on my Hackintosh, started OpenVPN GUI and was pleasantly surprised to connect right away with RDP using my internal hostnames (fully qualified, of course).

Now I knew it was something with Windows 7 on both my desktop, netbook and laptop.  But what could be affecting all three?  Many moons ago, Windows used to have odd problems associated with NIC binding orders.  I happened to notice in the ipconfig dump on the Virtual Box host that the TAP-Win32 adapter was listed first and as this was the NIC with the correct DNS settings to resolve my internal hostnames it looked like something I should check on the other systems.  Sure enough the desktop, netbook and laptop all had the TAP NIC listed in second place when I ran ipconfig /all.  Ah ha!  A quick google search for how to change Windows 7 NIC bindings (not where it used to be) turned up this gem from dillonator:

Get to the Network Connections page under the control panel. (If you’re looking at the Network and Sharing Center, click on Change Adapter Settings.) Now hit the “alt” key and you should see the menu pop up. Click on Advanced and you should know where you’re going from there

I love the fact that you have to press the ALT key to see the advanced settings options.  After moving my TAP-Win32 adapter (Local Area Connection 3) on my desktop to the top of the Connections list I was once again able to RDP into my remote hosts using their fully qualified domain names (FQDN).

NIC Bindings

I have no idea why or how the binding orders on three of my four Windows 7 RC1 installations changed or why my Virtual Box host was unaffected but I am happily VPNing with OpenVPN once more.   Any ideas on how this might have happened, please leave a comment.  Thanks.