Internal resources are slow over the VPN


I am using ISA 2006 on the server side and the Windows Client VPN on the client side for my VPN access.

Everything works, but when accessing internal network resources over the VPN it is very slow when using the server names, however when using the IP addresses of those same resources the access speed is fine.

It's more than likely an issue with the name resolution over the VPN but I am unable to find the solution.

Server shares over the VPN:
If I access \\server_name\share the access is very slow.
If I access \\ip_address\share the access is much faster.

Web apps over the VPN:
If I access http://server_name/intranet the access is very slow, 40 seconds to open the intranet home page.
If I access http://ip_address/intranet the access is fast, 4 seconds to open the same intranet home page.

I have tried using different clients to connect, XP and 7, I have tried using different servers as the ISA Server, I have tried allowing everything through the ISA Firewall, I have tried using PPTP instead of L2TP, etc - however nothing changes this, if I access internal resources by name it is slow, but by IP it is fast.

I have checked that the details I get fromt he DHCP server when connecting via VPN and compared these to the details I get when connecting locally and they are the same - the same IP range, DNS servers, WINS server, gateway, etc.


Who is Participating?
Daniel McAllisterConnect With a Mentor President, IT4SOHO, LLCCommented:
Sorry to contradict, but when you type an address in Windows as
the default Windows behavior is to attempt to use WINS to resolve the name first.

If you don't have WINS installed, this can cause delays -- but the REAL issue is that when your clients connect over the VPN, the VPN software updates the client's DNS settings to use the VPN resources, but NOT the WINS settings.

But there will be another problem (unless your server is Win 2008 and your clients are Vista or later):
 - REALLY OLD Windows systems (up to and including Me and NT) used NetBIOS (or NetBT) to handle naming and file sharing (using ports 137-139) -- and NEW Windows systems (Vista, 7, & 2008) will NOT use those protocols unless you specifically enable them in the Registry)
 - Old (but not THAT old) Windows systems (including 2000, XP, and 2003) use SMB (version 1) to do the same naming (including WINS) and file sharing -- but on port 445. HOWEVER, SMB version 1 is NOTORIOUS for its INSTABILITY (and thus, slowness) over Internet connections (especially VPNs) -- primarily because the protocols don't deal with latency very well.
 - Newer Windows systems (Vista, 7, and 2008) use an updated SMB (version 2) that makes WINS and file sharing much more reasonable over Internet connections.

The moral being -- don't use file sharing (SMB or CIFS) over a VPN unless your file sizes are rather small -- or unless you're using only newer Windows systems.

Sounds like exactly what you suspect - DNS resolution issues. A couple of things to try:

Use the FQDN of your server name (i.e. myserver.mydomain.local) instead of just the servername (i.e. myserver).

Try adding the hostnames / IPs of the server(s) to the hosts file on the client. Not the most elegant solution but should speed it up.


Pifco1Author Commented:
Thanks for the suggestions, I had already tried adding in the server names and IP addresses to the hosts file and it did not make any difference.

However, I had not tried the FQDN.

When accessing http://FQDN_of_Server/intranet the speed is as fast as when using the IP address, so that's some progress.

Do you have any idea why resolving the FQDN is so much faster than the server name?

As a note, the ISA server is not a domain mamber and is in the DMZ.
Not sure in what order WINS resolution takes place but you can add the servername to the LMHOSTS file as well. Here's a link that may help:
Pifco1Author Commented:
The name resolution over the VPN was down to WINS, not DNS.  

Clients could resolve the FQDN no problem using DNS, however we mostly use just the NetBIOS name of the servers which is down to WINS resolution.

I added the WINS role to the ISA Server and created a pull replication partnership with the internal WINS server and the server names are being resolved over the VPN as quickly as the FQDN's are now.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.