[pptp-server] Can't Ping a Thing

[Cowles, Steve]

> -----Original Message-----
> From: chuddles at coin.org [mailto:chuddles at coin.org]
> Sent: Tuesday, January 23, 2001 9:39 AM
> To: 'pptp-server at lists.schulte.org'
> Subject: Re: [pptp-server] Can't Ping a Thing
> 
> 
> I've see a few questions come across this list lately similar 
> to this one, where the client can't ping (telnet, ftp, etc)
> anything on the server's LAN. I'm experiencing this myself and
> am still waiting for someone to give a good answer here on the
> list.  Are you guys still having this problem?  Are people 
> responding to you privately?
> 
> Could one of the PPTP gurus maybe give a quick summary (or 
> point to one on the Net) of the internals that happen when
> a client connects to the server, such as what proxyarp does,
> how a packet gets from a client to a host on the server 
> LAN, etc.  I know I need to read up on how PPP works, but a 
> 'crash-course' on it would be awesome.  This is such a great
> product for a simple yet effective 
> VPN.
> 
> Thanks,
> Chris
> 

In order for any remote PPTP client to be able to ping any desktop PC or
server on your LAN (really vice-versa)... your PPTP server's LAN Ethernet
interface *MUST* be known as the proxy arp for your PPTP connection.
<PEROID> If you do not see the following entry in your /var/log/messages
file after you establish your PPTP VPN, you can forget about ever going any
further then your PPTP server from the remote PPTP client. (see below)

Jan 17 17:45:03 voyager pppd[14500]: found interface eth0 for proxy arp

Without going into the OSI network model and how a TCP connection is
actually established, a proxyarp tells your PPTP servers interface (eth0 in
this case) to answer arp requests on behalf of your PPTP client from other
Desktop/Servers on your LAN.

-----------------------------------------------------
Lets say that you have the following LAN design:
192.168.1.0/24 - Network address
192.168.1.1-254 - Addressable IP's for the above network address.
192.168.1.255 - Broadcast Address for the above LAN address.

Your PPTP servers IP address is:
192.168.1.1 = eth0

You also have a server on the LAN that has an address of:
192.168.1.100

You then establish a PPTP connection into your PPTP server from a remote
site and are given the following IP addresses:
local IP = 192.168.1.20 (ppp0)
remote IP = 192.168.1.200

Then, from the remote PPTP client, you try and ping the server at
192.168.1.100..

What basically happens is:
1) The remote PPTP client encapsulates an ICMP echo-request packet (ping)
with a destination address of 192.168.1.100 and forwards this across the
VPN. 

2) Your PPTP server receives this encapsulated packet at 192.168.1.20 (ppp0)
and then de-encapsulates it so that it can be properly routed using TCP/IP.

3) Based on your PPTP servers TCP/IP routing tables (netmask), it determines
that 192.168.1.100 can be reached through the eth0 interface and forwards
the packet from ppp0 to eth0.

Now, one of two things can happen:

If your PPTP servers TCP/IP stack already contains an "arp" entry (MAC
address) for 192.168.1.100...

4) Your PPTP servers TCP/IP stack will then route this packet to
192.168.1.100 (really its MAC address) via eth0.

If your PPTP servers TCP/IP stack does NOT contain an "arp" entry (MAC
address) for 192.168.1.100...

4a) It will first issue an arp request (on eth0) asking "Who has
192.168.1.100"
4b) If all is well, 192.168.1.100 will respond to the arp request generated
in step 4a by saying... "192.168.1.100 can be reached at this MAC address" 
4c) After receiving the arp reply from 192.168.1.100, your PPTP servers
TCP/IP stack will then route this packet to 192.168.1.100 (really its MAC
address) via eth0.

Whew!!! The ICMP echo-request (ping) has made it from 192.168.1.200 to
192.168.1.100. Now, 192.168.1.100 must reply to the ICMP echo-request by
sending an ICMP echo-reply back to 192.168.1.200. Basically, the same steps
occur as listed above, but only in reverse. 

Again, for the reply, one of two things can happen for step 1:

If the server at 192.168.1.100 TCP/IP stack already contains an "arp" entry
(MAC address) for 192.168.1.200 (the PPTP client)...

1) It will send the ICMP echo-reply packet directly to the PPTP servers eth0
interface (192.168.1.1).

If the server at 192.168.1.100 TCP/IP stack does not contain an "arp" entry
(MAC address) for 192.168.1.200 (the PPTP client)... This is where the proxy
arp comes in. 

1a) It will first issue an arp request asking "Who has 192.168.1.200"
1b) Since the PPTP servers eth0 interface is acting as a proxy for arp
requests on behalf of the PPTP client, it will respond to the arp request
generated in step 1a by saying... "192.168.1.200 can be reached through
192.168.1.1 MAC address" 
1c) After receiving the arp reply from 192.168.1.1, the server at
192.168.1.100 TCP/IP stack will then route this packet to 192.168.1.1
(really its MAC address)

2) Once the PPTP server has received the packet from 192.168.1.100... it
determines that 192.168.1.200 can be reached through the ppp0 interface
(based on the routing tables) and forwards the packet from eth0 to ppp0.

3) Now the PPTP server encapsulates this packet and forwards (routes) it on
to 192.168.1.200 (the PPTP client)

4) The remote PPTP client receives this encapsulated packet and then
de-encapsulates it so that it can then be routed using TCP/IP.

Thus completes our rather long journey. 

Obviously, an arp request does NOT say or contain data that says "I can be
reached at" This was my choice of words that hopefully helped some of you
understand basic TCPIP/PPP at a 30,000 foot level. Also note, that your PPTP
server is in essence, a router. i.e. It is routing packets of data from ppp0
to eth0 and vice-versa. Thus, you will need to insure that your ipchain
"forward" rules allow data that is received in ppp0 or eth0 to be forwarded
(routed). Thats another topic, but is also critical in getting "pings" to
work if eth0 is properly acting as a proxyarp.

Steve Cowles