Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


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
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I wrote this article to explain some important DNS concepts that should be known to avoid some typical configuration errors I often see in forums. I assume that what is described here is the typical behavior of Microsoft DNS client. I don't know …
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…

636 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