Some of my colleagues use the standard Microsoft VPN client to connect to the network at a subsidiary. I guess one day we may set up a site-to-site connection managed by the two routers, but for now we use individual connections. Here are some tips based on our experience.
DNS - accessing remote resources by name
When I first set the connections up I was given both the IP address and the name of a server on the remote network. I soon discovered that trying to browse to the server by name didn’t work so I just provided shortcuts to the IP address.
That was fine for accessing file shares but ran into problems with Outlook 2003, which was trying to connect to the remote Exchange server. Applying one of the standard email troubleshooting steps, I deleted the mail profile and recreated it; Outlook still wouldn’t connect. I then edited the profile to turn off cached mode; no joy. I restarted the PC. On restart, Outlook asked for the remote Exchange password but then told me “Your MS Exchange Server is unavailable”.
Once again I deleted the profile & started Outlook. Clearly Outlook could connect to the remote Exchange server because it verified the user name correctly. But then it would just repeat that the server was unavailable.
Finally I discovered that I needed an entry in the local “hosts” file on the client PC. To do this, I first started Notepad with Run as Administrator (this was a Windows 7 client and without the “admin” mode you can’t save files to the system area).�I then opened the “hosts” file from C:\Windows\System32\drivers\etc and added an entry something like this:
192.168.10.10 servername.domain_name.local
After saving the “hosts” file I found that Outlook would connect to the mailbox. Previously it would resolve the server name but not connect to the mailbox. No doubt Microsoft gurus could tell me why but I was happy with my fix.
By the way, having realized that I had a DNS problem I’d earlier tried specifying the remote network’s internal DNS server in the VPN configuration. But that meant I could resolve remote host names but no longer resolve my local ones! Using the hosts file gets round this.
Authentication to local resources
When one of our staff migrated from Windows XP to Windows 7 they discovered that when connected to the VPN they couldn’t browse to local file shares. There were also other peculiar symptoms, like not being able to start an app that pointed to a database on one of our servers. And printing reports to PDF from our ERP system would break as well.
At first I thought this was also DNS-related, having discovered that all nslookup commands were failing. This was because, by default, nslookup tried to use the DNS servers specified on the VPN configuration - which happened to be the remote network’s external ISP DNS servers - so no good for resolving internal addresses. To try to force the VPN to use our own local DNS servers, I specified those instead and reconnected. Although my nslookups started working we still had the same problems with accessing local resources.
Once again it was Google to the rescue. Articles like this and this showed me that this was an authentication problem, not DNS. The local PC was trying to use the VPN credentials to access the local resources. Not surprisingly, this fails (unless they happen to be identical, which would seem like a bad idea). It’s an issue we never saw with XP but happened every time with Windows 7.
A suggested workaround, at least for the file share problem, is to use the FQDN of your server. So instead of browsing to:
\\MyServer\Departments\MyDepartment (which doesn’t work)
I browse to:
\\MyServer.MyDomain.local\Departments\MyDepartment (which works)
Clearly this tells Windows which domain is being used and stops it using the VPN credentials. Although this works, it’s a bit clunky and didn’t solve all our problems. The final fix was to edit the rasphone.pbk file referred to in the articles and make the simple change from:
UseRasCredentials=1
To:
UseRasCredentials=0
This made all local resources work properly again, and because we have only a few users using a single VPN connection it’s not too onerous to apply.
Summary
These VPN glitches were frustrating but easy to fix in the end. I’m aware of at least one other gotcha to be aware of - having your Web browsing routed via the remote gateway (which you may not want, especially if the remote Internet connection is slower than yours) - but I wonder what else there is for my company to learn. What VPN problems have you faced and fixed?
