[pptp-server] Can't Ping a Thing

[chuddles at coin.org]

Thanks very much, Steve!  I think this is quality material that should go 
straight to the FAQ.  Thanks for taking the time to write it out for us all.
I'll be looking at arp tables and LAN IP traffic to see if I can get it to 
behave this way, as well as checking out the ipchains rules again.

-Chris

Quoting "Cowles, Steve" <Steve at SteveCowles.com>:

> > -----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
> 
> _______________________________________________
> pptp-server maillist  -  pptp-server at lists.schulte.org
> http://lists.schulte.org/mailman/listinfo/pptp-server
> List services provided by www.schulteconsulting.com!
>