Internal resources are slow over the VPN

Posted on 2011-03-03
Medium Priority
Last Modified: 2012-05-11

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.


Question by:Pifco1
  • 2
  • 2

Expert Comment

ID: 35028567
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.



Author Comment

ID: 35028780
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.
LVL 21

Accepted Solution

Daniel McAllister earned 2000 total points
ID: 35029657
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.


Expert Comment

ID: 35029978
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:


Author Closing Comment

ID: 35035459
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.


Featured Post

Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to Squarespace.com and use offer code ‘EXPERTS’ to get 10% off your first purchase.

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.

Join & Write a Comment

How to set-up an On Demand, IPSec, Site to SIte, VPN from a Draytek Vigor Router to a Cyberoam UTM Appliance. A concise guide to the settings required on both devices
Resolve DNS query failed errors for Exchange
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Suggested Courses

586 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question