2

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 setup is as follows:

Client (same problem on Windows and Android, haven't tested others) (ip: x.x.x.x) -> Internet -> (y.y.y.y) dd-wrt router (192.168.1.1) -> Ubuntu Server 10.10 running PPTPD (192.168.1.125).

eirik@woserv:~$ cat /etc/pptpd.conf | grep -v '#'

option /etc/ppp/pptpd-options
logwtmp
localip 192.168.1.125
remoteip 192.168.1.230-240

eirik@woserv:~$ cat /etc/ppp/pptpd-options | grep -v '#'

name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns 192.168.1.1
proxyarp
nodefaultroute
debug
lock
auth
nobsdcomp
noipx
mtu 1490
mru 1490

iptable rules (in /etc/rc.local) and verified is loaded using iptables -L

#!/bin/sh

# Flush all rules

iptables -F

iptables -X

iptables -Z

# Allow all VPN stuff

iptables -A INPUT -p tcp --dport 1723 -j ACCEPT

iptables -A INPUT -p 47 -j ACCEPT

iptables -A OUTPUT -p tcp --sport 1723 -j ACCEPT

iptables -A OUTPUT -p 47 -j ACCEPT

iptables -A FORWARD -i ppp+ -o eth0 -s 192.168.1.0/24 -m state --state NEW -j ACCEPT

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

exit 0

We've enabled PPTP, IPSEC and L2TP passthrough on the dd-wrt router (under Security -> VPN Passthrough). Also, we've port forwarded 1723 and 47 to 192.168.1.125.

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.

So far we've identified the following problem domains:

microsoft.com
support.microsoft.com
no.yahoo.com
answers.yahoo.com
nrk.no
imgur.com

(And while working on describing this problem, I discovered that I could not load http://w.pastebin.ca/pb-g.gz.js when I tried to access hxxp://pastebin.ca via the VPN)

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)

Eirik H
  • 125
  • 1
  • 9
  • 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! – Eirik H Jan 29 '13 at 21:37

2 Answers2

2

Since you changed the default MTU, this may be the cause. Try adding the following rule to your firewall, adjust as necessary:

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu

EDIT: changed the rule to insert itself as first in the chain.

fboaventura
  • 1,125
  • 11
  • 16
  • 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 Siu Jan 29 '13 at 12:09
  • Indeed removing the MTU and MRU may be a solution. – fboaventura Jan 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. – Eirik H Jan 29 '13 at 13:41
  • Where in your stack of rules have you put the rule? Have you checked that all the clients are hitting it? I had this same problem once and the solution was to clam the mss to mtu. – fboaventura Jan 29 '13 at 20:25
  • I put that rule last in our rc.local and re-run it with `sudo /etc/rc.local` which should flush all old rules and apply the new ones. Care to elaborate on how I would check "that all clients are hitting it?"? – Eirik H Jan 29 '13 at 21:25
  • you can check if the clients are hitting with `iptables -v`. Set the rule as the first in the `FORWARD` chain. – fboaventura Jan 29 '13 at 21:42
  • There we go! Amazing find, @fboaventura! Put that rule above all the other FORWARD rules and it now (magically) works on the two windows clients and an android phone I have available for testing. Thank you so much! – Eirik H Jan 29 '13 at 22:07
  • @eithe nice that solve it – John Siu Jan 29 '13 at 23:04
  • @fboaventura Can you explain a little(or point me to right direction) why `iptables -A FORWARD -i ppp+ -o eth0 -s 192.168.1.0/24 -m state --state NEW -j ACCEPT` does not cover your rule?? – John Siu Jan 29 '13 at 23:05
  • 2
    @John It's the clamp part that does the magic. Probably our ISP is to blame here, check out http://code.google.com/p/android-wifi-tether/issues/detail?id=816 or http://lartc.org/howto/lartc.cookbook.mtu-mss.html – Eirik H Jan 29 '13 at 23:31
  • @eithe Thank you very much. My miss conception was that rules was a protocol forwarding rules. But instead it is used to modify tcpmss, completely different thing. – John Siu Jan 29 '13 at 23:43
  • You guys figured out before I got to it. ;) – fboaventura Jan 30 '13 at 00:04
  • 2
    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 http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml – Radius Jan 31 '13 at 18:50
0

Multiple Issues

  1. /etc/ppp/pptpd-options

    nodefaultroute

    But Windows is setup with "Use default gateway on remote network". The above option should be removed.

  2. Same network on both side of NAT

    iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

    PPTP server has LAN IP of 192.168.1.125, PPTP clients are assigned 192.168.1.230-240, same 192.168.1.0/24 on both side of the NAT. Not sure it really works, partially works, but looks problematic.

    Additionally, PPTP server is already inside the LAN, DD-WRT router is doing out going NAT already. NAT on PPTP server is not necessary. Remove the above rule.

  3. Check /proc/sys/net/ipv4/ip_forward

    cat /proc/sys/net/ipv4/ip_forward should return 1. If not, add following as 2nd lines of rc.local

    echo 1 > /proc/sys/net/ipv4/ip_forward

  4. Check PPTP Client Network

    Check PPTP client local/LAN IP not using 192.168.1.0/24. They have to be changed or VPN routing may not work.

John Siu
  • 3,577
  • 2
  • 15
  • 23
  • 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. – Eirik H Jan 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 Siu Jan 29 '13 at 14:02
  • I am wondering if you are having dns issue, that's why I suggest the pinging test. – John Siu Jan 29 '13 at 17:03
  • Here is a [syslog of starting pptpd and getting a connection](http://pastebin.ca/2308641) (this is now using 192.168.2.0/24). Also, here is [me on one of the windows clients trying different stuff](http://pastebin.ca/2308645). – Eirik H Jan 29 '13 at 17:51
  • Oh, and entering http://160.68.205.231/ (dns for nrk.no) directly into the browser without VPN works fine, but under VPN, timeout. So probably not DNS ... – Eirik H Jan 29 '13 at 18:01
  • Blah, cant edit the comment above, the ping, tracert etc I did on the windows client address is wrong, this is the correct one: http://pastebin.ca/2308648 – Eirik H Jan 29 '13 at 18:19
  • So pping actually went through no problem. Even nslookup works for sites you have trouble visiting. What about traceroute to 8.8.8.8? – John Siu Jan 29 '13 at 18:45
  • Here is the [trace from a client with and without VPN](http://pastebin.ca/2308683). – Eirik H Jan 29 '13 at 19:12
  • I'm no network expert as you probably have noticed, but could it be something with that all the domains we're having issues with have multiple addresses or aliases when you dns resolve them? E.g. stackoverflow.com resolves to just a single IP and answers.yahoo.com give many + aliases? Just throwing out something I just noticed ... – Eirik H Jan 29 '13 at 19:18
  • It is perferctly normal for big web sites to have multiple IPs/aliases. So your traceroute to google is perfect. Can you try visite microsoft.com now. Also do a traceroute too if you have trouble. – John Siu Jan 29 '13 at 20:15
  • Yeah, I know many domains have multiple IPs/aliases, just found this common denominator with all the sites we are having issues with, and not the ones we are able to access like stackoverflow.com. Still same issues to microsoft.com, no access to hxxp://microsoft.com. What do you get when tracert to microsoft.com? I'm guessing a lot of "request timed out" for you, too. Also, they have blocked pinging microsoft.com. So yeah, basically same tracert to microsoft.com both on and off VPN. – Eirik H Jan 29 '13 at 20:30
  • (1) Yes, traceroute to MS actually cannot complete properly because hubs in middle disabled ping reply. However, traceroute to no.yahoo.com is successful, [link here](http://pastebin.ca/2308703). (2) Try to set `mtu` and `mru` to 1400. – John Siu Jan 29 '13 at 20:42
  • Here is my [traceroute and ping to no.yahoo.com](http://pastebin.ca/2308716). As you can see, both work, but give different IPs (dns load balancing or similar?). But no luck in any browser to load the web site when using the VPN. This is a very strange error that we've actually have had for several months. – Eirik H Jan 29 '13 at 21:19