We've been struggling with some kind of network/routing issue with a PPTPD based VPN where the clients can't access certain internet domains/ips through the VPN. As an example, the user can browse hxxp://google.com, but not hxxp://microsoft.com.

The VPN connection in Windows is setup with "Use default gateway on remote network" on IPv4 and uses MS-CHAP v2. If the clients access hxxp://www.whatismyip.com/ the correct VPN ip is reported (y.y.y.y) and not their normal internet IP, x.x.x.x.

If the clients try to open these web pages when they are using the VPN, they get a timeout (Google Chrome Dev Tools under Networking says "Pending" for the requests until they timeout). Sometimes Chrome says the error is "Error 101 (net::ERR_CONNECTION_RESET): The connection was reset.". Other services (besides http/https 80/443 also fail).

Most other sites work, like hxxp://google.com and hxxp://bing.com. The problems are consistent among many different windows and android clients from various locations. There are no proxies involved. Disabling Windows firewall and any anti-virus software does nothing.

tracert from the clients gives various results for the different domains, but they seem somewhat consistent between no VPN and VPN, here are some examples.

If I fire up lynx http://microsoft.com directly on the Linux server running PPTPD it loads up fine. Same with the other sites ...

Any ideas?

(sorry for the jsfiddle with the tracert links, could not post that many links here as a new user on ServerFault)

I'll stop by the office where the VPN is on my way to work tomorrow, and upgrade + factory reset the dd-wrt router. Thanks for all your help so far, guys, very much appreciated!
–
eitheJan 29 '13 at 21:37

Not sure if this is necessary as ... -A FORWARD -i ppp+ -o eth0 ... already forwarding all protocol. I was going to suggest removing the mtu an mru, but let see how things go.
–
John SiuJan 29 '13 at 12:09

Indeed removing the MTU and MRU may be a solution.
–
fboaventuraJan 29 '13 at 12:31

Thanks for this. We actually added MTU and MRU as part of our debugging. Tried to remove them again now (+restarted pptpd), but no difference. Then I applied the MTU and MRU again and added the rule, but still same problem.
–
eitheJan 29 '13 at 13:41

While this is already fixed, here is a good reference document about this, yes it's cisco but the reasons are better explained than on the rest of the answers cisco.com/en/US/tech/tk827/tk369/…
–
AndresSMJan 31 '13 at 18:50

Thank you, John Siu: [1] Added # before it [2] Ok, removed. [3] Yes, returns 1, as well as /etc/sysctl.conf with net.ipv4.ip_forward=1 [4]: Yeah, where I am now 10.x.x.x is used. Disconnected client, restarted pptpd and connected but still the same problem. As you suggested in [3] I'll setup the VPN to use 192.168.2.0/24 or something instead.
–
eitheJan 29 '13 at 13:53

If you do 2 already, test ping and dns from client to 192,168.1.1 and 8.8.8.8.
–
John SiuJan 29 '13 at 14:02

I am wondering if you are having dns issue, that's why I suggest the pinging test.
–
John SiuJan 29 '13 at 17:03