Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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)

share|improve this question
    
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! –  eithe Jan 29 '13 at 21:37

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer
    
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. –  eithe Jan 29 '13 at 13:41
2  
@John It's the clamp part that does the magic. Probably our ISP is to blame here, check out code.google.com/p/android-wifi-tether/issues/detail?id=816 or lartc.org/howto/lartc.cookbook.mtu-mss.html –  eithe Jan 29 '13 at 23:31
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 cisco.com/en/US/tech/tk827/tk369/… –  AndresSM Jan 31 '13 at 18:50

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.

share|improve this answer
    
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. –  eithe 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 (this is now using 192.168.2.0/24). Also, here is me on one of the windows clients trying different stuff. –  eithe Jan 29 '13 at 17:51
    
Oh, and entering 160.68.205.231 (dns for nrk.no) directly into the browser without VPN works fine, but under VPN, timeout. So probably not DNS ... –  eithe Jan 29 '13 at 18:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.