LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 04-24-2011, 09:44 AM   #1
jamescondron
Member
 
Registered: Jul 2007
Location: Scunthorpe, UK
Distribution: Ubuntu 8.10; Gentoo; Debian Lenny
Posts: 961

Rep: Reputation: 70
PPTP, Centos 5.5, Routing


Hi guys,

Not found a solution to this via the search function, nor have I via the usual channels (google, ddg, irc) so hopefully someone here will have an idea.

I've built pptp (Using the guide at http://blog.doylenet.net/?p=17), set the relevant IPs and users, and allowed the necessary ports in my firewall, and whilst I can connect I can't actually get out of the server, then, to the outside world.

When I connect /var/log/messages gives me:

Code:
Apr 24 14:13:14 duck pptpd[21361]: CTRL: Client 81.109.184.150 control connection started
Apr 24 14:13:14 duck pptpd[21361]: CTRL: Starting call (launching pppd, opening GRE)
Apr 24 14:13:14 duck pppd[21362]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Apr 24 14:13:14 duck pppd[21362]: pptpd-logwtmp: $Version$
Apr 24 14:13:14 duck pppd[21362]: pppd 2.4.4 started by root, uid 0
Apr 24 14:13:14 duck pppd[21362]: Using interface ppp0
Apr 24 14:13:14 duck pppd[21362]: Connect: ppp0 <--> /dev/pts/1
Apr 24 14:13:18 duck pppd[21362]: MPPE 128-bit stateless compression enabled
Apr 24 14:13:18 duck pppd[21362]: Unsupported protocol 'IPv6 Control Protovol' (0x8057) received
Apr 24 14:13:18 duck pppd[21362]: found interface eth0 for proxy arp
Apr 24 14:13:18 duck pppd[21362]: local  IP address 10.0.0.1
Apr 24 14:13:18 duck pppd[21362]: remote IP address 85.13.226.60
Apr 24 14:13:18 duck pppd[21362]: pptpd-logwtmp.so ip-up ppp0 jamescondron 81.109.184.150

# This is where I test my connection client side (for clarity)

Apr 24 14:14:00 duck pppd[21362]: LCP terminated by peer (MPPE disabled)
Apr 24 14:14:00 duck pppd[21362]: pptpd-logwtmp.so ip-down ppp0
Apr 24 14:14:00 duck pppd[21362]: Connect time 0.7 minutes.
Apr 24 14:14:00 duck pppd[21362]: Sent 0 bytes, received 39155 bytes.
Apr 24 14:14:00 duck pptpd[21361]: CTRL: EOF or bad error reading ctrl packet length.
Apr 24 14:14:00 duck pptpd[21361]: CTRL: couldn't read packet header (exit)
Apr 24 14:14:00 duck pptpd[21361]: CTRL: CTRL read failed
Apr 24 14:14:00 duck pppd[21362]: Modem hangup
Apr 24 14:14:00 duck pppd[21362]: Connection terminated.
Apr 24 14:14:00 duck pppd[21362]: Exit.
Apr 24 14:14:00 duck pptpd[21361]: CTRL: Client 81.109.184.150 control connection finished
So we're seeing no errors until I disconnect. The line 'Sent 0 bytes, received 39155 bytes.' is interesting though; it looks like the data isn't coming back- if I do

Code:
host kernel.org
Client side and watch with tcpdump on the centos server I see:

Code:
tcpdump -vv 'not port 3030 and not proto 47'

14:28:15.223009 IP (tos 0x0, ttl  55, id 50405, offset 0, flags [none], proto: TCP (6), length: 40) cpc9-walt14-2-0-cust149.13-2.cable.virginmedia.com.58232 > bradleydennis.com.pptp: ., cksum 0xbca6 (correct), 0:0(0) ack 1 win 33304
14:28:15.223030 IP (tos 0x0, ttl  64, id 58834, offset 0, flags [DF], proto: TCP (6), length: 52) bradleydennis.com.pptp > cpc9-walt14-2-0-cust149.13-2.cable.virginmedia.com.58232: ., cksum 0x69a1 (correct), 1:1(0) ack 1 win 496 <nop,nop,timestamp 18450639 963434176>
14:28:20.071190 CDPv2, ttl: 180s, checksum: 692 (unverified), length 378
	Device-ID (0x01), length: 31 bytes: 'acc8-b.bi05.enf.lon5.coreix.net'[|cdp]
14:28:35.235061 IP (tos 0x0, ttl  55, id 42970, offset 0, flags [none], proto: TCP (6), length: 40) cpc9-walt14-2-0-cust149.13-2.cable.virginmedia.com.58232 > bradleydennis.com.pptp: ., cksum 0xbca6 (correct), 0:0(0) ack 1 win 33304
14:28:35.235080 IP (tos 0x0, ttl  64, id 58835, offset 0, flags [DF], proto: TCP (6), length: 52) bradleydennis.com.pptp > cpc9-walt14-2-0-cust149.13-2.cable.virginmedia.com.58232: ., cksum 0x5617 (correct), 1:1(0) ack 1 win 496 <nop,nop,timestamp 18455641 963434176>
(bradleydennis.com is this server- its an outdated PTR I need to have a word with my colo company about).

So it looks like it should be working, though once again:

Code:
Apr 24 14:30:56 duck pppd[21469]: Connect time 4.0 minutes.
Apr 24 14:30:56 duck pppd[21469]: Sent 0 bytes, received 176705 bytes.
My firewall:

Code:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            icmp any 
ACCEPT     esp  --  anywhere             anywhere            
ACCEPT     ah   --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:mdns 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ipp 
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:arepa-cas 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:pptp 
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited
Which looks good to me. Routing details when a client connects:

Code:
85.13.226.61 dev ppp0  proto kernel  scope link  src 10.0.0.1 
85.13.226.56/29 dev eth0  proto kernel  scope link  src 85.13.226.60 
169.254.0.0/16 dev eth0  scope link 
default via 85.13.226.57 dev eth0
And ifconfig:

Code:
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:10.0.0.1  P-t-P:85.13.226.61  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1496  Metric:1
          RX packets:474 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:32363 (31.6 KiB)  TX bytes:84 (84.0 b)
The expected is to allow traffic over ppp0 to the outside world. The server IP and the VPN gateway being separate (though this happens when on the same). Unfortunately it isn't working as I expect; I can access the server on this IP, but not get out- the reason I'm using Point to Point and not other VPN type protocols is because I'm looking for precisely this behaviour.

Can anybody set me straight here?
 
Old 04-24-2011, 10:31 AM   #2
baldy3105
Member
 
Registered: Jan 2003
Location: Cambridgeshire, UK
Distribution: Mint (Desktop), Debian (Server)
Posts: 891

Rep: Reputation: 184Reputation: 184
Umm, not done much PPTP but I'll ask a question anyway as it doesn't look quite right to me.

From the log LCP is up, CCP is up as you have negotiated compression. IPCP is up because you have exchanged peer ip addresses, and IPv6 is failing to negotiate. So it looks like PPP negotiation is doing its thing OK. The sent 0 then would seem to indicate that the server has never found reason to send packets to that interface.

The PPP link is running unnumbered IP as they are negotiating 10.0.0.1 on one end, the server and 85.13.226.60 on the client. I would expect a host specific route to the PPP peer address 85.13.226.60. Your route table though has 85.13.226.61 via ppp0, which is surely wrong. Packets to 85.13.226.60 are going to route to eth0 outside of the PPTP tunnel.
 
Old 04-24-2011, 11:01 AM   #3
jamescondron
Member
 
Registered: Jul 2007
Location: Scunthorpe, UK
Distribution: Ubuntu 8.10; Gentoo; Debian Lenny
Posts: 961

Original Poster
Rep: Reputation: 70
Ah, good spot- I pasted in old data from /v/l/m; I changed it to .61 to avoid potential clashes.

Quote:
The PPP link is running unnumbered IP as they are negotiating 10.0.0.1 on one end, the server and 85.13.226.60 on the client.
Noted; I have knocked this around which, whilst output looks saner, connection still doing the same- IPs on this vlan I can ping, nothing else.


EDIT: First line should read 'I changed the IP later on to .61, .60 is the server IP and I was suddenly mindful of clashes'
 
Old 04-24-2011, 11:55 AM   #4
baldy3105
Member
 
Registered: Jan 2003
Location: Cambridgeshire, UK
Distribution: Mint (Desktop), Debian (Server)
Posts: 891

Rep: Reputation: 184Reputation: 184
OK so if I've got this right you're looking to come into the server from an internet based client but you're testing from your local network?


Code:
         85.13.226.56/29        .57
                  |--------------[router]-----------{internet}-------[client]
[server]----------|
       .60        |------[HOST]
                             .58
So you are connecting PPTP from the client and the client is hard configured with 85.13.226.61?

If I've read this right the server will have a 85.13.226.61 route because PPP adds a host specific peer route as you can see in your route table.

If another host, I've invented one assigned .58, needs to send to 85.13.226.61 its going to ARP for it. For this to work the linux serverv will need to proxy the ARP response so I assume that your linux box supports and is enabled for proxy-arp?

Last edited by baldy3105; 04-24-2011 at 11:57 AM.
 
Old 04-24-2011, 12:23 PM   #5
jamescondron
Member
 
Registered: Jul 2007
Location: Scunthorpe, UK
Distribution: Ubuntu 8.10; Gentoo; Debian Lenny
Posts: 961

Original Poster
Rep: Reputation: 70
The topology, or at least simplified is pretty much right, though to be clear:

Code:
      85.13.226.56/29:
                     

hardware-----------------network----------------{ internet }---------------------~client
85.13.226.58             85.13.226.57                                             xxx.xxx.xxx.xxx -> server assigns in 10.0.0.1/24
|               
vm-n             
85.13.226.60

* additional IP .61 used for vpn connection
If this makes sense.

As for arp-ing; I assume this is taken care of via the routing and with sysctl; otherwise this could be where I'm slipping up. For the sake of completeness:

Code:
sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
#snip
 
Old 04-24-2011, 01:09 PM   #6
baldy3105
Member
 
Registered: Jan 2003
Location: Cambridgeshire, UK
Distribution: Mint (Desktop), Debian (Server)
Posts: 891

Rep: Reputation: 184Reputation: 184
If you have physical network assigned as 85.13.226.56/29 all members of this subnet will reach each other by direct transmission. I.E they do not go via a gateway. This means that if .60 wants to reach .61 as far as he is concerned .61 is local so he can send an ethernet frame directly. To this end he will ARP for the MAC address belonging to .61.

.61 however has been assigned to the other end of the PPP connection as a host specific network. i.e. 85.13.226.61/32. The ARP will never make it to the actual owner of .61 so the .60 will never be able to construct an ethernet frame to transmit. To make this work your server would have to respond to the ARP itself as a proxy so that the IP packet can be sent to it for forwarding.

I'd have to look up proxy-arp for linux, never used it before.

EDIT:

http://www.redhat.com/archives/redha.../msg05074.html

seems to agree with me.
 
Old 04-24-2011, 02:14 PM   #7
jamescondron
Member
 
Registered: Jul 2007
Location: Scunthorpe, UK
Distribution: Ubuntu 8.10; Gentoo; Debian Lenny
Posts: 961

Original Poster
Rep: Reputation: 70
I don't think I've explained this as well as I hoped to; by:

Quote:
whilst I can connect I can't actually get out of the server, then, to the outside world.
in my first post I meant that yes, all this works, I can connect to it and so forth I'm hoping to get from my server to the outside world. I'm hoping that being connected to the vpn I can then (as my host example) tunnel out with with the point-to-point-tunnel protocol to the world.

In my example the address is 85.13.226.56/29 so, following normal vlan convention, .56 is the network address, .57 is the gateway and then hosts 58, 59, 60, 61 and 62 are host addresses with .63 as the broadcast.

Essentially the server is either not routing device ppp0 over eth0 (or eth0:0 in the case of using a separate vpn address) or it is doing so and not sending it back along ppp0. This is essentially what your link is saying; my question is how do I achieve this, assuming the rest of the settings are correct (As I believe they are since I can get from the client to the server like this when the connection is enabled)
 
Old 04-24-2011, 05:09 PM   #8
baldy3105
Member
 
Registered: Jan 2003
Location: Cambridgeshire, UK
Distribution: Mint (Desktop), Debian (Server)
Posts: 891

Rep: Reputation: 184Reputation: 184
The basic problem is that you have a host address that is part of a subnet on the end of a PPP connection via a router and none of the other members of that subnet are aware that the host is not local. As far as they are concerned that host is locally accessible.

Either enable proxy-arp on your server, which you should be able to do by -

echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

Not sure how you enable at boot-up but that should allow you to test the fix.

Otherwise you need to assign your client a different network address, say 172.16.0.1 than add a route on your default-gateway to 172.16.0.1 255.255.255.0 via 85.13.226.58.

That way you aren't relying on a workaround like proxy-arp to route for you. This will allow access to devices local to your server, but not access out to the internet as its a private address range, which may be a problem.
 
Old 04-24-2011, 05:56 PM   #9
jamescondron
Member
 
Registered: Jul 2007
Location: Scunthorpe, UK
Distribution: Ubuntu 8.10; Gentoo; Debian Lenny
Posts: 961

Original Poster
Rep: Reputation: 70
Hi,

Unfortunately this didn't work. What I may do is setup up some static routes in the morning when I'm in a position to get to my colo provider if I screw it up.

I'll come back to this thread and update it when I know better.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
How to Make PPTP routing jasem200 Linux - Networking 1 04-02-2010 01:04 PM
routing through pptp prashanlk Linux - Networking 1 11-26-2007 07:00 PM
pptp /routing question maybbach Linux - Networking 1 03-12-2007 02:37 PM
PPTP local routing tmchardy Linux - Networking 3 03-07-2006 04:13 PM
PPTP (MPPE) routing? nicholai Linux - Networking 0 02-16-2005 07:10 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 09:19 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration