[pptp-server] Subnets on the pptp host side

[Steve Rhodes]

I have seen a large number of posts regarding the problem of accessing
hosts on the server side of the pptp connection.  The typical post goes
something like

I have a pptp server set up on my office LAN.  I can connect to the
server and ping to it fine, but I can't ping any other hosts on the
office subnet.  I have ip-forwarding turned on and I have proxyarp set
in the ppp/options file.  What can be wrong?

There seem to be a lot of questions floating around about routing and
masq'ing associated with this issue.

Well, my curiosity got the best of me, so I thought I would check this
out.  Shown below is my test setup for investigating this problem.


192.168.8.142              192.168.56.10      192.168.56.11
192.168.56.12
 ________                 _______                 ______
______
|        |               |       |               |      |
|      |
| client |-------------->| fire  |-------------->| pptp |---------->|
host |
|        |               | wall  |               | srvr |
|      |
|________|               |_______|               |______|
|______|
    H                                               H
    H               192.168.8.10                    H
    H                                               H
    H===============================================H
192.168.5.12           pptp connection       192.168.5.11


For the sake of simplicity, we will ignore address translation issues
associated with the firewall.  This assumes that the client at
192.168.8.142 is going to use 192.168.56.11 as its target address for
the pptp connection to pptp_srvr.  The firewall will block all access to
the 192.168.56.0 subnet except for pptp connections associated with
pptp_srvr.  This can be implemented with ipchains

ipchains -P input DENY
ipchains -P forward DENY
ipchains -A input 192.168.56.0/24 -j ACCEPT    /* allow connections from
inside */
ipchains -A input -p tcp -d 192.168.56.11 1723 -j ACCEPT
ipchains -A input -p 47 -d 192.168.56.11 -j ACCEPT
ipchains -A forward -p tcp -d 192.168.56.11 1723 -j ACCEPT
ipchains -A forward -p tcp -s 192.168.56.11 1723 -j ACCEPT
ipchains -A forward -p 47 -d 192.168.56.11 -j ACCEPT
ipchains -A forward -p 47 -s 192.168.56.11 -j ACCEPT

When you connect from client to pptp_srvr, you will be able to complete
the connection and ping to pptp_srvr.  However, if you attempt to ping
host, at 192.168.56.12, this will fail.

A clue to this problem can be found in the /var/tmp/messages file on
pptp_srvr.  There, in the pppd messages, you will find

Cannot determine ethernet address for proxy ARP

This is due to an issue with the pppd program, which attempts to find a
hardware interface on the subnet to which the pppd client has been
assigned.  In this case its looking for a hardware interface on the
192.168.5.0 subnet.  It will fail to find one, and will drop the
proxyarp request.

The simplest way around this problem, and the one that is suggested in
the pppd documentation, is to set the pppd client IP assignment to be on
the local subnet.  An example in this case might be 192.168.56.129.
However, it may not be possible to do that.  In the case of a fully
loaded subnet, there may not be any addresses to spare.  Or there may be
some security issues with giving out local subnet addresses.  What to
do?

The place to look is in the arp table.  If you run tcpdump on host
(192.168.56.12) during the time when client is pinging, you will see
unanswered arp requests from host attempting to find the hardware
address for 192.168.5.12.  You need to proxy the hardware address of the
pptp_srvr for client in order for this request to be fulfilled.  This is
the job of proxyarp.  However, proxyarp has let us down in this
instance, and we need to find a workaround.

This can be done manually using the arp command on pptp_srvr.  For
example, if the hardware address of the ethernet card on pptp_srvr is
00:60:08:98:14:14, you could force the arp to proxy the client pptp
address by saying

arp --set 192.168.5.12 00:60:08:98:14:13 pub

You should now be able to ping from client to host through the pptp
connection.

This can be a problem, however, in a dynamic environment when clients
are logging into and out of the pptp server on a continuous basis.  One
way around this problem is to write a script that will execute upon the
initiation of each ppp connection.

The place to do this is in /etc/ppp/ip-up.  This script is executed each
time a new ppp connection is started.  It gets some variables passed
into it, one of which is the assigned IP address of the client.  Note
that RedHat systems use ip-up.local as the place for you to make the
script.  Don't forget to chmod +x !


#! /bin/bash

REMOTE_IP_ADDRESS=$5

date > /var/run/ppp.up
echo "REMOTE_IP_ADDRESS = " $REMOTE_IP_ADDRESS >> /var/run/ppp.up
arp --set $REMOTE_IP_ADDRESS 00:60:08:98:14:14 pub >> /var/run/ppp.up

exit 0


This should put you in business for accessing the remote subnet under
this scenario.  I am a little bit concerned, however, because I also
built a script ip-down.local, that should remove the arp proxy when
client disconnected.  It doesn't seem to do anything, however, and if I
try to delete the arp entry manually, it just spits out a cryptic error
message.  The arp entries remain persistent, as far as I can tell.  If
this is a problem or not, I don't know.  The next few clients that log
in are treated well, so I guess its OK.

I hope this information is useful to you, especially if you have
bothered to read the whole thing to this point, as it is rather lengthy!

Regards,

Steve Rhodes