1

I set up a pptp VPN server on a debian-squeeze server just fine, I can connect to it from Windows 7, but pinging any external hosts (like google.com) fails. Pinging 10.0.0.1 or 10.0.0.10 works as expected.

I have tried a lot so far but nothing has helped. Am I doing something wrong?

I set up pptpd with;

ms-dns 8.8.8.8
ms-dns 8.8.4.4

localip 10.0.0.1
remoteip 10.0.0.10-100

Added iptable rules;

iptables -A INPUT -p gre -j ACCEPT
iptables -A INPUT -p tcp --dport 1723 -j ACCEPT
iptables -A INPUT -i ppp+ -j ACCEPT
iptables -A FORWARD -i ppp+ -j ACCEPT
iptables -A FORWARD -o ppp+ -j ACCEPT

Enabled net.ipv4.ip_forward=1 in /etc/sysctl.conf

And added masquerading;

iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -o ppp0 -j MASQUERADE

Can anybody spot a mistake?

messages log:

Jun 20 15:25:01 server1 pppd[6089]: pppd 2.4.5 started by root, uid 0
Jun 20 15:25:01 server1 pppd[6089]: Using interface ppp0
Jun 20 15:25:01 server1 pppd[6089]: Connect: ppp0 <--> /dev/pts/2
Jun 20 15:25:05 server1 pppd[6089]: local  IP address 10.0.0.1
Jun 20 15:25:05 server1 pppd[6089]: remote IP address 10.0.0.10

debug log:

Jun 20 15:24:47 server1 pptpd[6053]: CTRL: Reaping child PPP[6054]

pptpd log:

Jun 20 15:25:01 server1 pptpd[6088]: CTRL: Client 8X.XX.2XX.X4 control connection started
Jun 20 15:25:01 server1 pptpd[6088]: CTRL: Starting call (launching pppd, opening GRE)
Jun 20 15:25:04 server1 pptpd[6088]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!

ifconfig on linux server:

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:10.0.0.1  P-t-P:10.0.0.10  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          RX packets:156 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:16390 (16.0 KiB)  TX bytes:137 (137.0 B)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:127.0.0.2  P-t-P:127.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:29264 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30152 errors:0 dropped:88 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4129198 (3.9 MiB)  TX bytes:25084183 (23.9 MiB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:1X9.XX.1XX.XX9  P-t-P:1X9.XX.1XX.XX9  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

ipconfig on windows client:

PPP adapter Chicago:

   Connection-specific DNS Suffix  . : 
   IPv4 Address. . . . . . . . . . . : 10.0.0.10
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . : 0.0.0.0

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : 
   Link-local IPv6 Address . . . . . : fe80::dc99:4aef:5221:b5e3%11
   IPv4 Address. . . . . . . . . . . : 192.168.1.102
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1

Tunnel adapter isatap.{290FC5BA-1A1F-48E5-9FAA-621E96CF4AED}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : 

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Connection-specific DNS Suffix  . : 
   IPv6 Address. . . . . . . . . . . : 2001:0:5ef5:79fd:2c53:3789:f5ff:fff5
   Link-local IPv6 Address . . . . . : fe80::2c53:3789:f5ff:fff5%13
   Default Gateway . . . . . . . . . : ::

Tunnel adapter isatap.{A22A1F34-B6D4-4BD7-BCA4-FAECB71D2D14}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : 

tracert -d www.google.com on client:

Tracing route to www.l.google.com [74.125.132.105]
over a maximum of 30 hops:

  1   117 ms   121 ms   117 ms  10.0.0.1 
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
Scott Pack
  • 14,717
  • 10
  • 51
  • 83
natli
  • 225
  • 2
  • 12
  • Does it work when you connect directly to the linux router NOT using vpn? Have you tried looking at the packets? Enabling logging in iptables? – symcbean Jun 20 '12 at 16:25

1 Answers1

2

You're not pushing the default gateway

PPP adapter Chicago:

Connection-specific DNS Suffix . : IPv4 Address. . . . . . . . . . . : 10.0.0.10 Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : 0.0.0.0

You need to make it point to 10.0.0.1 instead of 0.0.0.0

If that still doesn't work try

iptables -t filter -F

To verify if it's your firewall blocking the traffic, remember the order of the rules is important


Edit:

I see your NAT line is as follows:

iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -o ppp0 -j MASQUERADE

That's wrong, ppp0 is the VPN interface, you need to NAT on your WAN interface. I never use that masquerade thing... I always NAT this way:

iptables -t nat -A POSTROUTING -j SNAT -s 10.0.0.0/16 --to-source 1X9.XX.1XX.XX9

I guess 1X9.XX.1XX.XX9 is your public IP address, otherwise replace it with that.

Radius
  • 559
  • 2
  • 9
  • There is no way for me to push the default gateway on the VPN Connection. It does not provide that option in the TCP/IPv4 properties. Also, when I ping hosts on the client, it does resolve the domain name to an IP adress succesfully. But the requests time out. Flushing the iptable rules did not help, either. Also, I doubt the firewall is blocking anything, I think the problem is; [article](http://tomatousb.org/tut:configuring-a-pptp-vpn) - `We need to configure the firewall to both allow the incoming VPN connections and let VPN clients access your LAN and go out on the Internet` – natli Jun 20 '12 at 17:00
  • Resolving the names doesn't mean anything. Do a basic test, tracert -d www.google.com – Radius Jun 20 '12 at 17:13
  • Added tracert results to the question. – natli Jun 20 '12 at 17:28
  • Ok, I see the problem now, it's on my solution – Radius Jun 20 '12 at 19:22