A bunch of servers in our company headquarters in Sofia needed to be accessed on daily basis. Branch offices are connected to the Central through Internet. One of the branches is located Plovdiv. A vpn concentrator running pptp was installed in Sofia to provide remote access. I as wondering how to save me the trouble of configuring all Plovdiv workstations with vpn connections and keep an eye on demanding users.
I decided to set up an old linux box running Slackware 8.0 to act as a pptp client and route all employee traffic to headquarters through the vpn tunnel. While providing a transparent service I was able to limit the number of connections to one.
Files to change
To setup a pptp client the following files need to be modified:
|Linux configuration files|
/etc/ppp/options /etc/ppp/peers /etc/ppp/chap-secrets -if using chap for authentication as in our case /etc/ppp/if-up /etc/ppp/if-down /etc/rc.d/firewall -optionally to start vpn connection
To start with authentication.
PPP authentication is not necessarily bidirectional. Normally only clients authenticate with the server. In /etc/ppp/chap-secrets under client is provided the username, under secret the shared password, under server the server username if authentication is required. Usually a wildcard is used, which actually disables bidirectional authentication. The last field is the ip address of the server, again wildcarded to match any. If more than one ppp connection is configured with the same username and different password this may cause problems. But such cases are rare.
In /etc/ppp/peers directory a new config file is created bearing the name of the remote end. I named it “sofia”. Here, are specified connection parameters. Actually the missing ones are taken from /etc/ppp/options. So you can specify options in either places. At least the name must be specified, e.g. the username. In our case “plovdiv”. Another entry that must be present is:
|pty “/usr/sbin/pptp 184.108.40.206 –nolaunchpppd”, where 220.127.116.11 is the remote end ip|
The option ” –nolauchpppd” specifies that this pty is used for communication and not as a terminal device. It will not launch pppd and use stdin as network connection. In the background pppd will allocate a pseudo-tty master-slave pair. The script will be the slave terminal device with pty master as standard input/output. It is a good practice to explicitly set the mtu and mru value to 1460. The “file” entry in /etc/ppp/peers/sofia points to another file containing defaults for options not listed. Usually this is the /etc/ppp/options file. Yet another option – the “persist” option not surprisingly makes the connection persistent. If the connection is dropped it is reconnected automatically. Though it did not worked for me. You can try adding an entry in the /etc/inittab, something like this:
|pd:23:respawn:”/usr/sbin/pppd file /etc/ppp/peers/sofia”|
An interesting option is “ipparam”, though not used in our case. It is very handy if you have several peers. You set it in /etc/ppp/peers/peer_name and check it through the environment variable PPP_IPPARAM. Suppose I have to add one more tunnel – bourgas branch office. How can I know which connection is starting, which route to add, through which interface? I can match the ipparam string in ip-up script like this:
|Sample ip-up script|
if [$PPP_IPPARAM==”sofia”]; then
In our case a couple of lines are needed in ip-up script. It is executed on successful connection. So install the route for the remote network:
|route add -net 10.0.0.0 netmask 255.0.0.0 dev ppp0|
NAT all local LAN addresses through the pptp tunnel:
|iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o ppp0 -j MASQUERADE|
The script ip-down is executed when the connection terminates. Undo all created in ip-up (clear nat and delete routes).
| route del -net 10.0.0.0 netmask 255.0.0.0 dev ppp0
iptables -nat -D POSTROUTING -s 192.168.10.0/24 -o ppp0 -j MASQUERADE
The /etc/ppp/options and /etc/ppp/options.pptp files may be left at their defaults. If tunnel encryption is required you can add an entry in /etc/ppp/options:
Unfortunately Microsoft Point to Point Encryption is not compiled in linux kernel 2.4.x by default. First you have to patch the source and when compiling enable the option CONFIG_PPP_MPPE.
Everything worked as expected until the branch bought a new Cisco router – ISR 2801 as a replacement for the linux box. It turned out to be quite a challenge to configure the router to act as a pptp client. Still my efforts were not a waste of time. Below is a listing of the router configuration. Some parts are skipped for clarity. The router acts both as a pptp server, an Internet default gateway and a pptp client to Sofia. The pptp tunnel is established at startup and when terminated is reestablished automatically.
|Cisco router configuration|
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
!Very important. Allows to view some previously hidden commands
!the router is also acting as pptp server but this part of the config is skipped
!allow network access if authenticated
!perform PAT for vpn remote network
!always stay connected