[pptp-server] Subnets on the pptp host side (Take Two)

Steve Rhodes srhodes at cpinternet.com
Tue Aug 3 16:31:06 CDT 1999

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.
 ________          _______           ______        _____
|        |        |       |         |      |      |      |
| client |------->| fire  |-------->| pptp |----->| host |
|        |        | wall  |         | srvr |      |      |
|________|        |_______|         |______|      |______|
    H                                   H
    H              H
    H                                   H
    H===================================H     pptp connection

For the sake of simplicity, we will ignore address translation issues
associated with the firewall.  This assumes that the client at is going to use as its target address for
the pptp connection to pptp_srvr.  The firewall will block all access to

the 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 -j ACCEPT    /* allow connections from

inside */
ipchains -A input -p tcp -d 1723 -j ACCEPT
ipchains -A input -p 47 -d -j ACCEPT
ipchains -A forward -p tcp -d 1723 -j ACCEPT
ipchains -A forward -p tcp -s 1723 -j ACCEPT
ipchains -A forward -p 47 -d -j ACCEPT
ipchains -A forward -p 47 -s -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, 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 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
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

The place to look is in the arp table.  If you run tcpdump on host
( during the time when client is pinging, you will see
unanswered arp requests from host attempting to find the hardware
address for  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 00:60:08:98:14:13 pub

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

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


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!


Steve Rhodes

More information about the pptp-server mailing list