Linux Step By Steps

PPP SERVER

Written by Bill Parker on 2004-01-02 with  Assistance Provided by Kurt Wall and users rezidew and jgaddis on Undernet IRC #Linux channel.

Kurt provided initial source for info on this subject, since the PPP HOW-TO on sunsite.unc.edu/LDP is very out of date

Rezidew provided the ipchains line needed for ppp0 to surf from a MS DUN connection using an IP of your actual class C, instead of a masq'd private IP address.



System Tested: OpenLinux 2.2 & 3.1

How to run PPP Server on Linux (using a 2.2.x or 2.4.x based Kernel)

This document describes how to set up a Linux box that is on a network for dial in (modem) access (so far tested with win 95 client only), but should work for Win98/ME/XP, etc.

1. Things to ensure you have installed first:


IMPORTANT: The following commands below require ROOT access in order to be executed

Now on my machine, I have dual NIC's, and a(n) assigned class C for use in the office and the connection to the internet is a permanent one via a CISCO 3640 router (this is on eth0).  eth0 has a(n) assigned address of xxx.xxx.xxx.25 (Part of my Class C, the gateway for eth0 is the IP address of the router described above).
eth1 has a(n) assigned address of 192.168.3.1 (for IP masq client's in the office).  ppp0 has a(n) assigned address of xxx.xxx.xxx.150 (assigned in /etc/ppp/options.server).  The client logging into the linux box is assigned an address of xxx.xxx.xxx.151.  Note that the xxx.xxx.xxx.151, .150, and .25 are part of my assigned Class C.

2. Configuring mgetty to work with your system:

in /etc/mgetty+sendfax/mgetty.config, you should have the following options enabled (i.e. uncommented):

# US Robotics 28.8 External Data/Fax Modem on COM2 (ttyS1) no fax
#
port ttyS1
init-chat "" AT&F1&C1&D2
speed 115200
debug 3 <--- I used debug 9 when testing, lotsa stuff gets logged
data-only y

(this applies if your modem is on COM2, if it is on COM1/ttyS0) change the port line to ttyS0).

In /etc/inittab, you should have the following line, if not, then add it:

# Run gettys in standard runlevels
1:12345:respawn:/sbin/getty tty1 VC linux
2:2345:respawn:/sbin/getty tty2 VC linux
3:2345:respawn:/sbin/getty tty3 VC linux
4:2345:respawn:/sbin/getty tty4 VC linux
5:2345:respawn:/sbin/getty tty5 VC linux
6:2345:respawn:/sbin/getty tty6 VC linux
s1:2345:respawn:/usr/sbin/mgetty ttyS1 <---- This is the line I am talking about

Remember, ttyS0 = COM1, ttyS1 = COM2, ttyS2 = COM3, and ttyS3 = COM4

After making sure this file has the following information in it, issue the following command:

/sbin/init q <cr>

To make mgetty re-read the /etc/inittab file (i'm not sure if this needs to be done, but I did it anyways).  A good test to run first is to see if you can get access to your linux box via a terminal program (Hyperterm for windows is a good choice):

If you are able to connect to your linux box and get the login: prompt, proceed to step 3 "making sure pppd is set up properly".  Otherwise, go back and check your mgetty.config file in /etc/mgetty.config

Also another file to check is /etc/pam.d/login and make sure the following line is commented out:

auth required pam_dialup.so

insert a # in front of the line to comment out.

3. making sure pppd is set up properly:

PPPD will not run for regular users unless the sticky bit is set!!!  To set the sticky bit use (as root):

chmod u+s /usr/sbin/pppd <enter>

If you are running Red Hat Linux, pppd is under /sbin rather than /usr/sbin

ls -al of /usr/sbin/pppd (or /sbin/pppd) should look like this:

-r-sr-x--- 1 root root 138724 Sep 16 23:15 /usr/sbin/pppd

3.1 next the following information should be in /etc/mgetty+sendfax/login.config:

#
# Automatic PPP startup on receipt of LCP configure request (AutoPPP).
# mgetty has to be compiled with "-DAUTO_PPP" for this to work.
# Warning: Case is significant, AUTOPPP or autoppp won't work!
# Consult the "pppd" man page to find pppd options that work for you.
#
# NOTE: for *some* users, the "-detach" option has been necessary, for
# others, not at all. If your pppd doesn't die after hangup, try it.
#
/AutoPPP/ - @ /usr/sbin/pppd file /etc/ppp/options.server

The /AutoPPP line is the section to be concerned about, as there are other sections which do not apply to this HOW-TO...the file that pppd will read it's information from is in /etc/ppp/options.server. On OpenLinux 2.x
distributions mgetty is already compiled with -DAUTO_PPP, so it should be ok for use right out of the box.

3.2 in /etc/ppp/options.server the following information should be included:

#
# Auto Login for callin users
#
#proxyarp
asyncmap 0
netmask 255.255.255.0
crtscts
modem
lock
/dev/ttyS1 115200
ms-dns 198.6.1.3
ms-dns 198.6.1.1
-detach
+pap
#-chap
#
# Address of ppp0 on server side is xxx.xxx.xxx.150
# Address of ppp on client side is xxx.xxx.xxx.151
#
xxx.xxx.xxx.150:xxx.xxx.xxx.151

Now as you might notice, there is a small difference from the PPP HOW-TO document in terms of setting up PPP server...you will note that the proxyarp line in the file is commented out.  This is due to the fact that IP masq (via IPchains/IPtables) is being run on this box (and with the proper ipchains/iptables entry, proxyarp is not needed).
These options tell pppd to use PAP for authentication (which most 95/98/NT clients use).  The ms-dns entries should point to whatever primary and secondary DNS servers that you use on your box (the entries above are for UUnet, but don't use them unless you get your permanent net access from UUnet).

3.3 in /etc/ppp/pap-secrets the following information should be present:

# Secrets for authentication using PAP
# client server secret IP addresses
#
* * "" *

The last line allows any user in /etc/passwd (shadow or non-shadow password) to log in and use PPP

4. At this stage a user should be able to log in and connect to a system like the one which I have described above (2 NIC's, IP masq, single modem)...however, you may find that the remote client (in my case I used a win95 machine to make the remote connection) is unable to surf the web or ping addresses on the internet (except for xxx.xxx.xxx.150 or .151 or .25).  If this happens, don't panic, but look at the next section below (this took me a week to solve with the help of several people):

After logging in, if you issue the following commands (one at a time):

w <enter> (you should get output which may look something like you see below)
5:03pm up 31 days, 5:06, 2 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
/AutoPPP ttyS1 31200/ARQ/V34/LA 4:03pm 1:00m 0.05s 0.05s pppd file /etc/ppp/options.server
billp ttyp1 192.168.3.4 1:39pm 0.00s 0.35s 0.05s w

/sbin/ifconfig <enter>

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:234378 errors:0 dropped:0 overruns:0 frame:0
TX packets:234378 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

eth0 Link encap:Ethernet HWaddr 00:A0:C9:E3:F8:8D
inet addr:xxx.xxx.xxx.25 Bcast:xxx.xxx.xxx.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12096640 errors:0 dropped:0 overruns:0 frame:0
TX packets:10929152 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:11 Base address:0x6000

eth1 Link encap:Ethernet HWaddr 00:A0:C9:67:EE:E5
inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10964114 errors:0 dropped:0 overruns:0 frame:1
TX packets:10149109 errors:0 dropped:0 overruns:0 carrier:0
collisions:86419 txqueuelen:100
Interrupt:10 Base address:0x6100

ppp0 Link encap:Point-to-Point Protocol
inet addr:xxx.xxx.xxx.150 P-t-P:xxx.xxx.xxx.151 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:237 errors:0 dropped:0 overruns:0 frame:0
TX packets:203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10

Do NOT let the NOARP entry on ppp0 disturb you at this point.

/sbin/route -n <enter>

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
xxx.xxx.xxx.151 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
xxx.xxx.xxx.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 xxx.xxx.xxx.128 0.0.0.0 UG 1 0 0 eth0

Note that where you see xxx.xxx.xxx entries, this should correspond to your Class C that you were assigned, and the last entry in the table under "Gateway" should be the IP address of your router.  In order to get the remote client to work, an addition to ipchains/iptables was needed since my machine uses IP masq for clients inside the office:

/sbin/ipchains -A forward -s xxx.xxx.xxx.151 -d 0.0.0.0/0 -j ACCEPT

or if you are using iptables (most everyone is these days):

/sbin/iptables -A FORWARD -s xxx.xxx.xxx.151 -d 0.0.0.0/0 -j ACCEPT

This allows information to go back and forth over the ppp0 interface which would have come up when the connection was made (the above entry is only needed if you are assigning IP's to your clients which are part of your actual class C, if you are assigning an IP address which is already being masq'd on a NIC (i.e. eth1 as listed above in the routing table, you do not need the above line).  At this point, if you are logged into the box from a win 95/98 or NT client,
you should be able to ping some sites on the internet (i.e. www.ibm.com, etc).  If you are able to do this, you have dial in PPP Server working on your machine.

I almost forgot, when you bring down the ppp connection, there is a chance that the ppp0 interface may NOT be removed, and in addition, the route for ppp0 may NOT be removed. To insure the interface and route are removed each time ppp0 is brought down, add the following lines below to the bottom of 'if-down' in /etc/ppp:

/sbin/route del $5
/sbin/ifconfig $1 down

This should insure that the route and interface configuration are removed each time a ppp connection is broken. If not, then re-check all of the information presented above. 

Be advised, I have not tried this with a machine which only has a single NIC installed as eth0 and getting pppd running, but the process should be very similar to what has been described above.

Advanced information for PPP Server:

In doing additional research on my own, I have found that the /dev/ttySx line in section 3.2 does not appear to be needed, as I commented the line out on my system, and dial in access continues to work.

The other issue is with security, if you have a machine like mine using Dual NIC's, and you don't want to assign parts of your actual Class C block (costs the company $$$ mind you), you can use ipchains to allow the use of private ip addresses in the range of 192.168.x.x.

As an example, if I were to use private ip addresses on the host and client side, it would look something like this:

192.168.2.150:192.168.2.151 (where 150 is what ppp<n> is assigned on your linux box),

and 151 is what the machine dialing into your box receives as an actual ip address.

If you are planning to connect more than one modem to your computer, I believe the following will work in /etc/inittab:

Add entry which looks like this for 2nd modem (assume 1st modem is on com1)

s1:2345:respawn:/usr/sbin/mgetty ttyS1

and then issue /sbin/init q to respawn.

Also, if you are using more than one modem, you will want to set up individual /etc/ppp/options.ttySx files which contain the host and client ip addresses (for example):

in /etc/ppp/options.ttyS0 I have

192.168.3.150:192.168.3.151

and in /etc/ppp/options.ttyS1 I have

192.168.3.152:192.168.3:153

so in the event a user dials in on com1, he is assigned the ip address 192.168.3.151 and if another user dials in on com2, they are assigned ip address 192.168.3.153 (be advised that this requires a 2nd NIC, and proper setup of
gateways, etc for use with ipchains/iptables).

I have not tried this dual modem monster as com1 on my production box is broken, but it should work w/o any problems.

Logins that are idle for long period's of time:

In some cases, where you have a limited number of modems, you may wish to log users off who are idle for a specified period of time (say an hour or more). However, in trying to use the idle command in the /etc/ppp/options file, I have not been able to get it to work on a consistent basis. I recommend instead the use of IDLED instead of idle in PPP options, as it runs and can disconnect any logged in user, not just dial in connections.