Link to home
Start Free TrialLog in
Avatar of baleman2
baleman2

asked on

VPN connection causes local network speed Issues

This is a "reopening" of another question I asked a week or so ago.  I thought the resolution was complete but am still having problems.
Attachment may be helpful in understanding my explanation below.

My home office's Linksys VPN router handles all traffic.  The Linksys sits behind an ISP supplied modem that is in full bridged mode.  I have a Public Static IP assigned by my ISP.  The Linksys has a Static IP of 192.168.3.1 assigned to it.  For DNS the Linksys is assigned the IP's supplied by my ISP, 12.223.xx.xxx.  The Linksys hands out IP's based on the 192.168.3.xx addressing scheme.  

There is an Access Point (bridged mode) connected to one of the ethernet ports of the Linksys and provides wireless connectivity throughout my home office.  Static IP address of this IP is 192.168.3.2.  So, all wireless devices are handed a 192.168.3.xx address.  This AP is also configured with Gateway and DNS IP's of 192.168.3.1 - thus pointing to the Linksys.

On one of the home office wireless clients, I have an outgoing VPN connection to my business network.  I use the Windows built in VPN Client for connectivity.  It connects to a Meraki firewall at the edge of the network.  This Meraki is configured to hand out IP's to VPN clients using the 192.168.25.xx addressing scheme.  In our domain we have our own Primary and Secondary DNS servers, 10.18.30.5 and 10.18.30.10, respectively.

As long as I don't use my VPN connection to my business network, all client PC's work extremely fast in my home office environment.

When I use my VPN client to reach my business network, the connection does get established.
 However, once established, reaching any server on the business network (via RDP from a home office PC) can take minutes - sometimes so long that the connection times out.  Home Office connectivity to the internet slows dramatically.

The Windows VPN client has settings that control the TCP/IP connectivity for just this adapter.  I have already unchecked the box to "Use default gateway on Remote Network", but it has not resolved any speed issues.  

I believe it's a DNS issue.  There are several settings available for DNS entries in the Windows VPN client, but I'm unsure of how best to configure these settings.  I'm hoping the information shown in the attachment will help in diagnosing the problem.
Avatar of baleman2
baleman2

ASKER

I forgot the document - here it is.
IPCONFIG_ALL.docx
Avatar of CompProbSolv
"I believe it's a DNS issue."
There is a simple test for that.  Try to use RDP to a server using the server's IP address.  That will skip DNS altogether.

It is entirely possible that the Wireless LAN's DNS setting (192.168.3.1) is being used to resolve the server name first.  It eventually times out and the 10.18.30.5 is then used successfully.

I've worked this out with other VPN clients where I can designate what DNS to use after the connection is made.  I don't know how to do it (or if it can be done) with the Windows client.

In any case, start with accessing by IP to confirm that DNS really is your issue.
One of the servers I reach regularly is our Exchange Server.  I can ping the IP address of this server while on the VPN.  Logging on via RDP with this server's IP address still takes a minute or more.  Longer than normal.  I must add that the home office Linksys is a new addition to my home network.  Before that, there was no incoming VPN connections from remote clients - only my one outgoing connection to the business network.  Before the Linksys, the modem supplied by my ISP was the only device in my home office network.  Although I've had several calls with Linksys tech support, they've been no help in resolving this issue.
As long as you are not using any device on the 192.168.3.0/24 network you most probably need to use the DNS servers on the other side of the VPN.
(for pubic DNS as well as the remote AD site).

If you still need local access you can enter them in the host file or possibly use  a local DNS server on your system to forward (zone forward) the queries for the AD domains accross the the VPN and all other local.
"Logging on via RDP with this server's IP address still takes a minute or more."
I'd run Resource Monitor (from the Performance tab in Task Manager) and watch what is going on with the network connection.  Is there infrequent traffic or is it pretty steady?
I doubt that the VPN is responsible for slow RDP, unless you've got a TCP fragmentation issue.
Remember that RDP will try network level authentication prior to sending RDP login data, and that won't work from outside the office, and a fallback is tried if allowed. That causes a severe delay, so 1 minute or so for connecting is common.


As said above, you have to exclude potential culprits by performing tests as simple as possible:

I'm sure we solved the routing issue in the prior question.

We did not consider DNS - which, as has been told, usually has to point to the VPN server DNS to be able to resolve targets. Windows can't use more than one active DNS server (despite the first comment of CompProbSolv might look like contradicting). Only if a DNS server does not answer at all, that is it is not reachable, a secondary DNS server is queried. noci posted the correct answer to this part of the issue.

And then there is TCP fragmentation, which slows down traffic and  (usually) makes RDP unusable (breaking the connection very often). To check if this might be an issue, use mturoute -t target.ip.addr.ess. If it shows a severe degration of MTU, try if setting a lower MTU (and restarting the VPN) helps.
The command to set a different MTU of 1300 is
netsh interface set interface LAN mtu= 1300

Open in new window

where LAN is your network interface name.
@Qlemo:
Thank you for the clarification.  My initial comment, as you implied, was likely incorrect.  I was thinking of DNS servers not responding as opposed to a DNS server saying "I can't resolve that".

This does raise an interesting question, though.  According to the ipconfig /all, there are two adapters, HLC_TT_VPN and Wireless.  The first uses DNS servers on the 10.18.x.x network where the Wireless uses 192.168.3.1.  How does Windows decide which one to use when resolving a name when initiating an RDP session?
For the HLC_TT_VPN adapter:
Network and Sharing Center->Change Adapter Settings->Properties->Networking Tab at top->Highlight IPv4->Properties
Here are available settings that I think would address CompProbSolv's question.
A click on the "Advanced" tab provide even more granularity related to this adapter - in particular, the DNS settings.  I have not experimented with manual entries here.
DNS setting are applied globally, not per adapter. Windows decides in the process of connecting which setting it sets with precedence - usually the VPN settings win, overruling the original DNS settings. That is similar to what it does with the default gateway, if its change is part of the VPN connection.
@qlemo:
If one runs nslookup from a CMD prompt, it shows which DNS server it is using for that particular lookup.  Is it safe to assume that this is the first DNS it will use for any lookup?
Yes, that is safe to assume - unless unreachable.
NSLOOKUP while disconnected from the VPN:
     Default Server:  Unknown
     Address:             192.168.3.1      (IP Address of Home Office Router)

NSLOOKUP while connected to the remote network via VPN:
     Default Server:  dc1.hlc.local    (Domain Controller which is also DNS server plus FQDN name)
     IP Address:         10.18.30.5       (IP Address of remote network DNS Server)
So the remote DNS is used while connected. But that shouldn't make DNS request slow enough to have a severe impact on Internet connections.
If you set the local DNS server in your TCP settings again after connecting via VPN, your local DNS server should get used again. You can test again with nslookup as above. If that works, try if Internet browsing is faster.
It's not sounding as if it is a DNS issue if the symptoms appear when you access the server by IP address with RDP.

What happens if you try to access a file share using Start, Run, \\<server ip address>?  There should be several steps:
1)  Prompt to log in to the server
2)  Showing server shares after successful login
3)  Opening a file share
4)  Copy a file from the server to the local computer

It would be useful to know which of those steps is fast and which is not.
On my home pc, I have a mapped drive that drills into our File server which has a share named TT_Docs.
Drive letter Z: is mapped to \\FS1\TT_Docs
Before access via the VPN, this mapped drive always has a red "X" on it.  After enabling my connection via the VPN, I always have to click on the mapped drive in order to re-establish the connection and open it up to see all the sub-folders.  This happens (right now) very fast - as fast as I'm accustomed to.
I just copied a 3mb file from that folder to my local home pc and that also completed as fast as I expect it to.
The main problem seems to be superslow (or nonexistent) connections to my saved websites when I'm connected via VPN to the remote network.
In other words, 1, 2, 3, and 4 are completing in the expected time frame.  Internet connectivity is the culprit.
@CompPropSolv, there are 2 issues
However, once established, reaching any server on the business network (via RDP from a home office PC) can take minutes - sometimes so long that the connection times out.  Home Office connectivity to the internet slows dramatically
and we both are talking about different ones. You are correct about DNS & RDP.
After the last comment it really looks like "anything in the office works fast", if we leave RDP aside. That is good to know. How about RDP, is it the only slow "office" feature?

The second issue  - slow Internet -  has to be viewed separately. Please try my suggested DNS "hack", so we can hopefully make sure whether DNS slows down everything.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.