Why does my PC lose Internet connectivity when I connect to a VPN service?

August 23, 2012 2:50 AM

I am trying to setup a router with DD-WRT & OpenVPN so that I can stream content from Netflix/Hulu etc. when living outside the US. However, every time I connect to the VPN service my PC connected to the router loses internet connectivity.

I currently have a Buffalo Buffalo WZR-HP-G300NH2 router (Router 1) connected to a Motorola Surfboard modem. This is the primary router in my household that most devices connect to.

Router is running DD-WRT v24SP2(build 19152) that Buffalo provides, and is configured as follows: WAN IP- DHCP, Router IP-192.168.0.1, DHCP Server - 192.168.0.100~254

I have a 2nd router D-Link DIR-825 (Router 2) running DD-WRT v24SP2 (build 18777). This router is configured
as follows: WAN IP- Fixed IP 192.168.0.2/Gateway -192.168.0.1/Static DNS - as per ISP, DHCP Server - 192.168.1.100~120. Router 2's Firewall is disabled, with only Filter Multicast checked.

I have setup a 2nd subnet with Router 2 as I intend to use devices like a Roku 2 & a Kindle with the VPN and these only support DHCP connections. The two subnets are linked via Static Routes in Router 1.

When the VPN is disconnected, any PC connected to Router 2 can connect to the Internet/other PC's on the LAN without problems. Once the VPN is active though, Internet connectivity breaks.

I think there is some problem with the routing in Router 2 (ha-ha). Before the VPN is connected, the routing table looks like this:

Kernel IP routing table 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth1 
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo 
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1 
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 eth1 
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0 

After I connect the VPN, the routing table looks like this:

Kernel IP routing table 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
0.0.0.0         10.12.0.37      128.0.0.0       UG    0      0        0 tun0 
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth1 
10.12.0.1       10.12.0.37      255.255.255.255 UGH   0      0        0 tun0 
10.12.0.37      0.0.0.0         255.255.255.255 UH    0      0        0 tun0 
107.6.113.82    192.168.0.1     255.255.255.255 UGH   0      0        0 eth1 
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo 
128.0.0.0       10.12.0.37      128.0.0.0       UG    0      0        0 tun0 
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 br0 
173.193.223.172 192.168.0.1     255.255.255.255 UGH   0      0        0 eth1 
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1 
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 eth1 
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0 

My limited understanding of routing suggests the presence of multiple default routes is not good, but googling for solutions has not yielded anything useful. Ask Mefi, please help!

posted by your mildly obsessive average geek to Computers & Internet (10 answers total)

Sorry if this is a little off topic (good luck with your actual question) but I've had good success using unblock-us.com to achieve the same thing, it lets you access US and UK sites from outside the correct countries and all you have to change is your DNS server.

I'm pretty sure it has a free one week trial, so there's no down side to checking it out.
posted by tiamat at 4:51 AM on August 23, 2012

I don't think thats your issue looking at the routing table all of these either route private ip's 10.X.X.X and/or for a single ip because of the 255.255.255.255 mask. Looking it up more generally seems to result in two things either its an issue with them being on the same subnet as the other router or you need to enable split tunneling. Google
posted by Rubbstone at 5:14 AM on August 23, 2012

I live in the UK and use Proxmate. Easy peasy, though it doesn't satisfy your desire to use a 2-router & VPN solution.
posted by Emperor SnooKloze at 5:47 AM on August 23, 2012

Response by poster: Tiamat - Actually the VPN provider provides a similar DNS service. Although this unblocks services like Netflix, there is a list of sites (don't know which all) that is blocked by ISP's here. That can only be overcome with the VPN tunnel.

Rubbstone - split tunneling is to force some traffic out of the VPN yes? But actually I want everything to go through the VPN. Actually the router itself is fine, it's just the PC behind it that doesn't go anywhere.
posted by your mildly obsessive average geek at 6:28 AM on August 23, 2012

I think the problem is what information Router2 is handing its clients via DHCP. PCs on that network get ip addresses of 192.168.1.x and default gateways of 192.168.0.1, right?

So when the VPN is turned on, the clients still have 192.168.0.1 as their default route. They are going to keep trying to use Router1 as their gateway for all their internet traffic. Which they won't be able to do because (if the VPN is working) router2 is trying to route all the traffic over the VPN.

What you need to do, I believe, is make the DHCP server on router2 hand out its own ip address as a gateway. Then packets will arrive at router2 and they will be forwarded out the VPN if it is enabled, and out the regular way when it isn't.

My limited understanding of routing suggests the presence of multiple default routes is not good, but googling for solutions has not yielded anything useful. Ask Mefi, please help!

It's only not good as a symptom of something not being configured exactly right. Routing tries the most specific route first, which in this OS looks like it goes from the bottom up. So the second default route wouldn't matter because no traffic ever gets to it. Which, if I'm reading correctly, means that no traffic ever actually hits the VPN. You might try running a traceroute to make sure the traffic is really going across the VPN.
posted by gjc at 7:10 AM on August 23, 2012

gjc,

If Router 2 were handing out 192.168.0.1 as a default gateway for DHCP, then the PCs would never get out of the local subnet anyway -- unless you're doing proxy ARP on the router (unlikely) then having a default route with a non-local gateway is pretty much useless. I'd have to assume that R2 is providing its own IP (192.168.1.1?) as the default gateway to the clients.

The routing table makes sense to me, actually -- there's only one default route (0.0.0.0/0), which points out to R1 (192.168.0.1), making it the gateway of last resort. However, the VPN is providing two /1 routes that point out the tun0 interface. Since routing always takes the most specific route (i.e., the longest prefix), then any traffic going out R2 when the VPN is up will match either the 0.0.0.0/1 route (which covers 0.0.0.0-127.255.255.255) or the 128.0.0.0/1 route (which covers 128.0.0.0-255.255.255.255), and will go out the tunnel in either case, so the default route to 192.168.0.1 will never be used.

So no obvious problems with the routing -- I'd look at the DNS, actually. On R2, what DNS servers is it handing out to DHCP clients?

Let's say R2 hands out your local ISP's DNS servers to the clients. If the VPN's up, then DNS traffic from the clients on R2 will be routed out the tunnel, not to R1 and thus to the ISP's DNS servers. Quite possibly the ISP blocks outside access to those DNS servers, so when the traffic goes through the tunnel and comes back to the ISP from the US, it gets blocked.

I think the best configuration is this (not overly familiar with DD-WRT config, but I'd hope it's possible):

1) R2's DHCP server gives R2's own IP to DHCP clients as a DNS server.
2) R2's DNS server (probably dnsmasq or similar?) is configured to forward DNS queries to either R1, or to the ISP's DNS servers. The server IPs go in /etc/resolv.conf.

At this point, here's what should happen when the VPN comes up:
1) The VPN client puts the VPN provider's DNS servers into R2's /etc/resolv.conf
2) dnsmasq picks up the change and starts forwards queries from clients behind R2 to the VPN provider's DNS servers instead of either R1 or the ISP's DNS servers.

One thing to test -- can you ping or traceroute to the IPs of Google's free DNS servers (8.8.8.8 and 8.4.4.4) when the VPN is up? If so, then it's almost certainly a DNS issue instead of a connectivity issue.
posted by McCoy Pauley at 7:33 AM on August 23, 2012

You're right, I mis-parsed his explanation and forgot my low-level arp stuff. Ignore my answer.

I agree, you probably need to do DNS proxying on router2.
posted by gjc at 8:26 AM on August 23, 2012

Response by poster: McCoy - You've described the symptoms exactly! Once the VPN is connected, I cannot ping or traceroute to any Internet IP.

I did some checking of the different files you have mentioned and found the following:

1. Prior to the VPN connection, /etc/resolv.conf shows 192.168.1.1
2. After the VPN connection, it gets updated to 8.8.8.8 (the Google DNS IP).
3. However, the dnsmasq.conf file shows that dnsmasq refers a different file - /tmp/resolv.dnsmasq
4. Before & after the VPN connection, there is no change in /tmp/resolv.dnsmasq.

Searching for threads about DNS problems in OpenVPN, I found this thread. The thread-starter mentions that in order to get DNS requests answered by his VPN DNS server, he had to uncheck the option "Prevent DNS rebind attacks". Looking at the man page for dnsmasq, I see that this setting makes dnsmasq "Reject (and log) addresses from upstream nameservers which are in the private IP ranges". I'm wondering if the routing for the VPN being in the private IP range and the dnsmasq settings are conflicting.
posted by your mildly obsessive average geek at 11:47 PM on August 23, 2012

Best answer: Interesting -- I'm not sure how DD-WRT manages dnsmasq configuration (whether by command-line flags or a config file like /etc/dnsmasq.conf. I think the --stop-dns-rebind option is designed to prevent a situation where you query an upstream DNS server for a public site and it gives you back a private RFC1918 IP (e.g., you ask for google.com and it gives you a 192.168.0.x address -- this could be part of an attack where an attacker uses your browser to probe other hosts on your local network). If you're forwarding DNS queries from R2 to R1, though, then it might make a difference for resolution of internal hosts.

I think there's something nonstandard in the way DD-WRT is configuring your dnsmasq daemon, though. Normally, dnsmasq would find the upstream servers to forward to from /etc/resolv.conf. If you've got 192.168.1.1 (the IP of R2) in resolv.conf, that means that local DNS lookups would be forwarded to the dnsmasq daemon, but it also means that dnsmasq is getting its upstream servers from somewhere else, probably via the -S/--server flag and the -R/--no-resolv flag (which explicitly tell it which servers to forward to, and not to read /etc/resolv.conf, respectively).

One interesting possibility would be to configure the DHCP on R2 to give out the Google DNS servers (8.8.8.8 and 8.4.4.4) to clients, so they'd bypass dnsmasq and always go to those servers. Should work for lookups whether or not you're on the VPN, but you'd lose the ability to resolve hosts on your private network by name. Might be a good experiment, though.

There's some other problem, though, if you can't ping or traceroute at all by IP while the VPN is up. Make sure to tell traceroute and ping not to try and resolve hostnames, because that could cause long delays that look like failures. (On Windows, ping doesn't resolve by default, and use "-d" to keep tracert from doing it. On Linux, use "-n" with both ping and traceroute to keep them from trying to resolve.) Also, can you ping or traceroute from R2 itself when the VPN's up? Since the routing on your side looks OK, the other possibilities I can think of are:

1) Firewalling on R2 (but you did say that's disabled)
2) NAT on R2 (is there any being done, or is that disabled along with the firewalling?) I don't know how your VPN provider handles client IPs coming from behind a VPN-connected device. It's quite possible they only want to see the IP of the tunnel endpoint, since they probably don't want to deal with your 192.168.1.x addresses.
3) NAT or routing somewhere downstream at the VPN provider.

#2 seems the most fruitful possibility to investigate. Can you find any indication that R2 is doing source NAT/PAT on the outbound traffic through the tunnel? If not, you probably need to enable that. (Again, not sure of DD-WRT config details, but you would want to configure interface PAT for outbound traffic through the tun0 interface.)

Also, you mention using a Roku box and a Kindle behind the R2 device -- do those work at all when the VPN's up, or do they have the same problem as the PC clients do?
posted by McCoy Pauley at 8:43 AM on August 24, 2012

Response by poster: McCoy - #2 was the right answer! I had previously linked the two routers following this guide on the DD-WRT wiki, but the wiki article recommended switching R2 to "Router" mode instead of "Gateway" mode. In "Router" mode, it would not do NAT which was likely causing the problem with the VPN connection.

Once I switched Router 2 to "Gateway" mode, the VPN tunnel started working right away not just for PC's but also for the Roku I plugged in. Oddly enough, switching to "Gateway" did not make any difference as far routing between the two subnets goes, so I'm not sure why the wiki insisted on that particular change.

Time to mark the question as resolved :)
posted by your mildly obsessive average geek at 12:29 AM on August 26, 2012