[ale] Setting up dialin ppp (long)

Ben Coleman oloryn at benshome.net
Fri Jun 22 16:05:45 EDT 2001


>In a nutcase, this is the situation. I have a home network hosted on a
>RH6.2 box feeding into a dsl line. I want to add the ability to dial in
>by normal phone line and have the remote system join the household
>network via ppp.


I've got this set up, except I'm using Slackware.  The following should
work, but won't take advantage of (if any) any GUI setup RH might have for
this.

>Reading the mgetty stuff, I can now dial in to the hosting system and
>login as a shell account, which would at least work in the near term for
>my still limited need. I would prefer to be able to run ppp, and properly
>surf via gui and all that.

You could set up a user(typically ppp) that automatically runs pppd upon
login, but it's better to set up to recognize ppp immediately upon connect.
See the mgetty docs about AutoPPP.  If your mgetty hasn't been compiled with
it enabled(with -DAUTO_PPP), you may have to recompile mgetty.  Once this
has been done, you basically need to make an entry in mgetty's login.config.
Mine looks like:

/AutoPPP/ -     a_ppp   /usr/sbin/pppd call remote


I use the 'call remote' parameters to force pppd to get its options from
/etc/ppp/peers/remote (see the 'call' parameter in the pppd docs), rather
than from /etc/ppp/options.  This keeps options for the dialin from possibly
conflicting with those for other pppd users (say, PPPOE, if your ADSL line
uses that, or outbound ppp).  My /etc/ppp/peers/remote looks like:

lock
modem
#debug
netmask 255.255.255.252
passive
auth
ms-dns 172.17.113.3
ms-dns 172.17.113.6
mru 1412
mtu 1412
172.17.114.1:172.17.114.2
ipparam remote

>The issues I'm confused about are assigning the
>hosting ip address, the remote(laptop) ip address

That's what the '172.17.114.1:172.17.114.2' line is for above.  Note that
I've set this up as a separate /30 network (see the netmask above).  My
internal netowrk is on 172.17.113.0/28.  Also, you need to assign the remote
address (the second one) in your papsecrets/chapsecrets file for the
username entry you use for the remote dialin.  E.g., mine looks something
like:

dialin             morannon        <password>      172.17.114.2

With this, the remote user dials in set up with 'dialin' as the username and
<password>  as the password (you didn't think I was going to publish my own
password, did you?), and is assigned 172.17.114.2 as the remote ip address.
With only one phone line, I couldn't see any reason for doing anything other
than a staticly assigned ip address.

>, routing so the
>remote(laptop) machine is a full member of the internal network,

pppd will set up a route to the remote machine on the dialup receiving
machine.  If this is the same machine that you have set up doing ADSL,
you're all set, as you probably have that machine already set up as the
default route for your internal network.

If you have more than the typical 3-line masquerade for firewall rules(as I
do), you'll also need to add rules to allow packets to flow to and from the
remote connection, allow forwarding between the remote connection and your
internal lan, and set up masquerading of connections from the remote
connection to the outside world.  The best place to handle this is in the
/etc/ppp/ip-up and /etc/ppp/ip-down scripts that are run when a PPP
connection goes up and down respectively.  Note that this is why I specify
'ipparam remote' in the above option file.  This makes pppd add 'remote' as
the 6th parameter when calling ip-up and ip-down.  This allows this code in
ip-up:

# The following should not be run when establishing a remote dialin
connection
if [ "$6" != "remote" ]; then
        # set up firewall rules
        /etc/ppp/connected.rules $1 $4
        if [ -e /etc/ppp/remote_exists ]; then
                /etc/ppp/remote_up.rules `cat /etc/ppp/remote_exists`
        fi

        # report our new ip address to hn.org
        /usr/local/sbin/hammernode.pl $4
else
        # Add firewall rules for the remote connection
        /etc/ppp/remote_up.rules $1
        echo $1 >/etc/ppp/remote_exists
fi

and this code in ip-down

# The following should not be run when taking down a remote dialin
connection
if [ "$6" != "remote" ]; then
        /etc/ppp/disconnected.rules
else
        # turn off remote firewall rules
        /etc/ppp/remote_down.rules
        rm /etc/ppp/remote_exists
fi

to distinguish whether it's being run for an inbound (remote dialin) or an
outbound (PPPOE or modem connection to the ISP) connection and do the
appropriate things.  The remote_up.rules script sets up the appropriate
firewall rules for the dialin, and remove_down.rules removes them.  Note
also that I create and remove /etc/ppp/remote_exists(which, when it is
there, contains the name of the interface the dialin is connected as) to
show whether or not there's a remote connection.  This is because
connected.rules (the script that gets run when an outgoing connection is
made) rebuilds the firewall rules from scratch.  The remote_exists files
allows me to check if there's already an inbound connection and re-run the
remote_up.rules script.  If I didn't do this, then if an outbound connection
is an inbound connection existed (not at all unusual, as one of the reasons
I might dial in is to find out if the ADSL connection is down and to
re-connect it), the inbound connection would, for practical purposes lose
connectivity (the PPP connection would still exist, but firewall rules
wouldn't let any packets through).


>and probably DNS since the internal net has a DNS server running.


See the ms-dns entries in my options file above.  This will pass the ip
addresses of DNS servers to use to the remote machine.  Win32 machines can
be configured to pick these up and use them.  Remote Linux machines dialing
in will probably need to have code inserted in their /etc/ppp/ip-up to pick
up these and use them (from the environment variables DNS1 and DNS2,
provided that the option usepeerdns is specified to pppd).



I think it's obvious that setting this up can get a bit involved.  Read up
on the pppd man page - I think you'll be quite familiar with it by the time
you get everything set up.

Ben

--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.





More information about the Ale mailing list