VPN clients connected to 2012 R2 VPN server having trouble browsing the web; accessing internal network resources is fine

Hey all,

I've got a Server 2012 R2 VPN server setup, and it works great except for the fact that clients connected to it have trouble browsing the web, or just generally accessing most things outside of our corporate LAN. Let me say in advance that corporate policy dictates that VPN clients have to use the default gateway on the remote network, so we can't simply disable that setting to fix the issue.

The symptoms are this: VPN clients aren't able to browse anything on the web, with a few weird exceptions like Google, and one or two other random websites. Everything else times out. Name resolution works fine- I do an nslookup on one of the clients, I get answers instantly. If I do a tracert to one of the websites I can't reach, all traffic hits our VPN server as the first hop, then dies. If I watch this process on our corporate firewall, I don't see any traffic going from the VPN client out to the internet. Networking seems to mostly be fine on the VPN server- I can browse the web and everything, but for some reason if I do a tracert anywhere outside the network, everything times out.

We've tried a couple different network configurations on the VPN server. We've got two NICs, one pointed to the corporate LAN, one pointed to the DMZ. Currently we have a static IPs and default gateways configured on both NICs, and we've gone back and forth between two different configurations otherwise: one scenario where the internal LAN NIC is accessed first, and both NICs are configured with DNS servers, and one where the DMZ NIC is configured to be used first, but does not have any DNS servers configured. Both configurations seem to work for our purposes, but we're seeing the same problem with clients being unable to browse the internet with both.

The Windows Firewall is disabled for the internal LAN connection, but enabled for the DMZ connection. I haven't opened any ports in particular on the firewall, however.

I've tried several different encryption/authentication combinations, and I see the same behavior with all of them.

The clients that are connecting to this server are either Windows 7 or Windows 8.1, if that makes a difference, and we're seeing the same behavior on all of them.
Graham StarfeltSystem AdministratorAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Rob WilliamsCommented:
Firstly, on the server,  Windows does not support more than one "Default" gateway, however it sounds more like a DNS issue.  As a test from a VPN client machine try connecting to a problematic web page using only its IP.  Note that not all sites can be accessed in this way.  
One site that should work is   http://4.79.142.202  (GRC - Gibson Research).

If this works OK, in the VPN client under the VPN adapter's TCP/IP properties, set your office DNS server's IP under DNS.  The VPN client is probably trying to use its DNS settings from Its physical NIC but cannot do so be cause of the Use remote default gateway option.
Graham StarfeltSystem AdministratorAuthor Commented:
DNS is working fine on the clients, actually. I can resolve names without any trouble and, using your example, I'm unable to browse websites by going directly to the IP rather than the URL.

Also, I've tried changing the network configuration so that there's only a single default gateway, but that doesn't seem to work, either.
Rob WilliamsCommented:
Very odd.
It pretty well has to be a routing or a DNS issue.  I assumed DNS as you said you can access Google and 2 other sites.  If it was routing you would not be able to access any.

One other thought; what do you have for a router at the server site?  Many routers such as Cisco have a device limit. For example 25.  The 26th user trying to access the Internet is blocked. It will not affect incoming traffic or local/LAN access, just traffic to the Internet.

If you run tracert to a public IP from a VPN client, how far does it get?
Are You Protected from Q3's Internet Threats?

Every quarter, WatchGuard's Threat Lab releases a security report that analyzes the top threat trends impacting companies around the world. For Q3, we saw that 6.8% of the top 100K websites use insecure SSL protocols. Read the full report to start protecting your business today!

Graham StarfeltSystem AdministratorAuthor Commented:
Tracerts arrive at the VPN server on the first hop and then hang from there on out. Since I'm sure you'll ask, here are the results of a route print on a VPN client:
routeprint.JPG
And here is the routing table on the server:
vpnserverroutingtable.JPG
Those 192.168.4.X addresses on the client side are on the corporate LAN.
Rob WilliamsCommented:
I am afraid I find those routing tables a little confusing, however it appears the corporate LAN uses a 192.168.0.0 subnet with subnet mask 255.255.0.0 ?  If so, it also appears the VPN client uses  192.168.1.0 with 255.255.255.0  Those subnets overlap.  Though that will not usually cause a problem when connecting to the server itself, so long as "use remote default gateway" is selected, it will cause routing issues to other devices such as the corporate router.  VPNs must have different subnets (not overlaping or the same) at either end of the tunnel.
Graham StarfeltSystem AdministratorAuthor Commented:
Alright, so I went ahead and changed my home network to a 172.168.1.0/24 network, and I still saw the same behavior when connected to the VPN. Any further suggestions?
Rob WilliamsCommented:
What typically happens is the traffic reaches the router, but is lost on the return, however you say you do not see any traffic from the VPN client in the router logs, or do you now?
Now that you have different subnets you have eliminated one routing issue.  

Not only do you need a route to the router, but a return route.  The latter is what is usually missing. Typically the VPN client and server can communicate as they know the route to contact each other as they have local entries in their routing tables.  Keep in mind a device only knows the next hop, and nothing beyond.  If it doesn't have a route, it sends it to the default gateway.  Thus when a VPN client tries to connect to the internet 123.123.123.123 it sends it to the server as it is it’s “Remote default gateway”.  The server can resolve it due to DNS, but does not have a route for 123.123.123.123 so forwards it to its default gateway, the router.  It in turn sends it to its default gateway, your ISP and Internet.  The packet is returned, but the router does not know how to contact your VPN client as it is connected to one NIC of the server and the VPN client the other.  Thus router then needs a static route added to tell it the next hop to reach the VPN client, via the server.
Graham StarfeltSystem AdministratorAuthor Commented:
So when I look at the traffic on the firewall/router, I do see connections going out from the VPN client to the website I'm trying to get to. The logs are showing the traffic as originating from the VPN server, which makes sense to me. However, the client itself is still not able to reach the website- it just times out.
Rob WilliamsCommented:
Exactly.  When the packet is returned the router does not know the route to the VPN client.  The router needs a static route added, assuming it supports that.  

However I missed something.  You said you changed your home network to 172.168.1.0/24.  That is not a private network so you can have issues trying to resolve that to a public IP.
The private networks are:
192.168.x.x
10.x.x.x
172.16.x.x to 172.31.x.x
Graham StarfeltSystem AdministratorAuthor Commented:
Alright, so what would that route look like? Our VPN clients are just pulling DHCP addresses from the same domain controller providing addresses for for local workstations. Would we need to restrict them to a specific address range so that the router could route traffic appropriately? Or is there some clever approach to this that I'm not realizing?
Rob WilliamsCommented:
My appologies.  I just moved to O365, missed adding this address, and thus didn't see untill now.

There is a simple way to do this;  If you use a single NIC, rather than a separate NIC or DMZ for the VPN, then within RRAS assign an IP in the same subnet as the the local LAN clients, you shouldn't have to add any routes using this method.

A lot of VPN "how to's'" recommend a separate NIC for VPN users for security but I fail to see any advantage as they already have access to your server.  If concerned about security you should be using a VPN capable router and a proper IPsec client such as with Cisco, Sonicwall, Juniper, WatchGuard and a few others.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
VPN

From novice to tech pro — start learning today.