Revision History | ||
---|---|---|
Revision 2.0 | 2002-05-30 | Revised by: tab |
Updated to Docbook 4.1 and applied GFDL per Matthew Wilson | ||
Revision 1.0 | 1999-12-01 | Revised by: mdw |
Initial release |
This document is broken down into 5 chapters.
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled "GNU Free Documentation License".
If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for Back-Cover Texts.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
The original "VPN mini-HOWTO" was written by Arpad Magosanyi, <mag@bunuel.tii.matav.hu>, in 1997. He has since allowed me to take up the document and extend it into a full HOWTO. All of this would not be possible without his original document. Thanks again Arpad. :)
Version 1.0 of this HOWTO was completed on December 10, 1999.
Put simply, to make a VPN, you create a secure tunnel between the two networks and route IP through it. If I've lost you already, you should read The Linux Networking Overview HOWTO to learn more about networking with Linux.
Here are some diagrams to illustrate this concept:
\ \ -------- / / -------- Remote ______| Client |______\ Internet \_____| Server |______ Private Network | Router | / / | Router | Network -------- \ \ -------- / / Client Router ---------------------------------------------------- | /-> 10.0.0.0/255.0.0.0 \ | Remote | |--> 172.16.0.0/255.240.0.0 |--> Tunnel >---\ | Network >---|--|--> 192.168.0.0/255.255.0.0 / |--|----> Internet 192.168.12.0 | | | | | \-----> 0.0.0.0/0.0.0.0 --> IP Masquerade >--/ | ---------------------------------------------------- Server Router ---------------------------------------------------- | /-> 10.0.0.0/255.0.0.0 \ | | /--> Tunnel >--|--> 172.16.0.0/255.240.0.0 |--|----> Private Internet >--|--| \--> 192.168.0.0/255.255.0.0 / | Network | | | 172.16.0.0/12 | \-----> 0.0.0.0/0.0.0.0 -----> /dev/null | 192.168.0.0/16 ---------------------------------------------------- |
The above diagram shows how the network might be set up. If you don't know what IP Masquerading is, you should probably read the The Linux Networking Overview HOWTO and come back once you understand how it works.
The Client Router is a Linux box acting as the gateway/firewall for the remote network. The remote network uses the local IP address 192.168.12.0. For the sake of a simple diagram, I left out the local routing information on the routers. The basic idea is to route traffic for all of the private networks (10.0.0.0, 172.16.0.0, and 192.168.0.0) through the tunnel. The setup shown here is one way. That is, while the remote network can see the private network, the private network cannot necessarily see the remote network. In order for that to happen, you must specify that the routes are bidirectional.
From the diagram you should also note that all of the traffic coming out of the client router appears to be from the client router, that is, all from one IP address. You could route real numbers from inside your network but that brings all sorts of security problems with it.
There are of course other ways of setting up a VPN. Here are a couple of other systems:
PPTP is a Microsoft protocol for VPN. It is supported under Linux, but is known to have serious security issues. I do not describe how to use it here since it is covered by the Linux VPN Masquerade HOWTO.
Since this server is going to be on both sides of your firewall, and set up to forward traffic into your network, it's a good idea to secure the box as well as you possibly can. You can read up more on Linux security in the Linux Security HOWTO. In this case I killed everything but sshd and a Roxen Web server. I use the web server to download a couple of files (my scripts, etc) for setting up new machines to access the VPN. I don't use an FTP server since it's harder to configure one to be secure than it is to just make a few files available with a web server. Plus, I only need to be able to download files. If you really want to run different servers on your gateway, you might want to think about restricting access to them to only those machines on your private network.
Here's how a typical /etc/passwd file looks:
... nobody:x:65534:100:nobody:/dev/null: mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash joe:*:504:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd bill:*:504:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd frank:*:504:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd ... |
Note that I've done more than just editing the second field. I'll explain the other fields later on.
User access is done via ssh's authentication scheme. As stated above, this is how users get access to the system, while maintaining a high level of security. If you're not familiar with ssh, check out http://www.ssh.org/. Note that I am using ssh version 1, not version 2. There is a big difference, notably that version 1 is free, and 2 isn't.
PermitRootLogin yes IgnoreRhosts yes StrictModes yes QuietMode no CheckMail no IdleTimeout 3d X11Forwarding no PrintMotd no KeepAlive yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication no PermitEmptyPasswords no UseLogin no |
If you decide to not allow users to have shell access, then the best way to keep them from gaining it is to make their shell pppd. This is done in the /etc/passwd file. You can see /etc/passwd file that I did this for the last three users. The last field of the /etc/passwd file is the user's shell. You needn't do anything special to pppd in order to make it work. It gets executed as root when the user connects. This is certainly the simplest setup to be had, as well as the most secure, and ideal for large scale and corporate systems. I describe exactly what all needs to be done later in this document. You can Section 5.7 if you like.
Now that your users have access to the system, we need to make sure that they have access to the network. We do that by using the Linux kernel's firewalling rules and routing tables. Using the route and ipfwadm commands, we can set up the kernel to handle network traffic in the appropriate ways. For more info on ipfwadm, ipchains and route see the Linux Networking HOWTO.
In order for any of this to work, you must have your kernel configured correctly. If you don't know how to build your own kernel, then you should read the Kernel HOWTO. You'll need to make sure that the following kernel options are turned on in addition to basic networking. I use a 2.0.38 kernel in my system.
For 2.0 kernels:
CONFIG_FIREWALL
CONFIG_IP_FORWARD
CONFIG_IP_FIREWALL
CONFIG_IP_ROUTER
CONFIG_IP_MASQUERADE (optional)
CONFIG_IP_MASQUERADE_ICMP (optional)
CONFIG_PPP
For 2.2 kernels:
CONFIG_FIREWALL
CONFIG_IP_ADVANCED_ROUTER
CONFIG_IP_FIREWALL
CONFIG_IP_ROUTER
CONFIG_IP_MASQUERADE (optional)
CONFIG_IP_MASQUERADE_ICMP (optional)
CONFIG_PPP
To set the rules with ipfwadm, run it with options similar to the following:
# /sbin/ipfwadm -F -f # /sbin/ipfwadm -F -p deny # /sbin/ipfwadm -F -a accept -S 192.168.13.0/24 -D 172.16.0.0/12 |
To set the rules with ipchains, run it with options similar to the following:
# /sbin/ipchains -F forward # /sbin/ipchains -P forward DENY # /sbin/ipchains -A forward -j ACCEPT -s 192.168.13.0/24 -d 172.16.0.0/12 |
Assuming that 172.16.254.254 is the internal gateway: # /sbin/route add -net 10.0.0.0 netmask 255.0.0.0 gw 172.16.254.254 dev eth1 # /sbin/route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.16.254.254 dev eth1 # /sbin/route add -net 192.168.0.0 netmask 255.255.0.0 gw 172.16.254.254 dev eth1 |
# /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish -i /root/.ssh/identity.vpn -l joe > /tmp/vpn-device # sleep 10 # /usr/sbin/pppd `cat /tmp/vpn-device` # sleep 15 # /sbin/route add -net 172.16.0.0 gw vpn-internal.mycompany.com netmask 255.240.0.0 # /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 255.255.0.0 |
If you don't want to have to type those commands in every time that you want to get the tunnel running, I've written a set of bash scripts that keep the tunnel up and running. You can download the package from here. Just download and uncompress it into /usr/local/vpn. Inside you'll find three files:
vpnd: The script that controls the tunnel connection.
check-vpnd: a script to be run by cron to check that vpnd is still up.
pty-redir: a small executable needed to initialize the tunnel.
You'll need to edit the vpnd script to set things like the client's username and the server's names. You may also need to modify the starttunnel section of the script to specify which networks you are using. Below is a copy of the script for your reading enjoyment. You'll note that you could put the script in a different directory, you just need to change the VPN_DIR variable.
#! /bin/bash # # vpnd: Monitor the tunnel, bring it up and down as necessary # USERNAME=vpn-username IDENTITY=/root/.ssh/identity.vpn VPN_DIR=/usr/local/vpn LOCK_DIR=/var/run VPN_EXTERNAL=vpn.mycompany.com VPN_INTERNAL=vpn-internal.mycompany.com PTY_REDIR=${VPN_DIR}/pty-redir SSH=${VPN_DIR}/${VPN_EXTERNAL} PPPD=/usr/sbin/pppd ROUTE=/sbin/route CRYPTO=blowfish PPP_OPTIONS="noipdefault ipcp-accept-local ipcp-accept-remote local noauth nocrtscts lock nodefaultroute" ORIG_SSH=/usr/bin/ssh starttunnel () { $PTY_REDIR $SSH -t -e none -o 'Batchmode yes' -c $CRYPTO -i $IDENTITY -l $USERNAME > /tmp/vpn-device sleep 15 $PPPD `cat /tmp/vpn-device` $PPP_OPTIONS sleep 15 # Add routes (modify these lines as necessary) /sbin/route add -net 10.0.0.0 gw $VPN_INTERNAL netmask 255.0.0.0 /sbin/route add -net 172.16.0.0 gw $VPN_INTERNAL netmask 255.240.0.0 /sbin/route add -net 192.168.0.0 gw $VPN_INTERNAL netmask 255.255.0.0 } stoptunnel () { kill `ps ax | grep $SSH | grep -v grep | awk '{print $1}'` } resettunnel () { echo "reseting tunnel." date >> ${VPN_DIR}/restart.log eval stoptunnel sleep 5 eval starttunnel } checktunnel () { ping -c 4 $VPN_EXTERNAL 2>/dev/null 1>/dev/null if [ $? -eq 0 ]; then ping -c 4 $VPN_INTERNAL 2>/dev/null 1>/dev/null if [ $? -ne 0 ]; then eval resettunnel fi fi } settraps () { trap "eval stoptunnel; exit 0" INT TERM trap "eval resettunnel" HUP trap "eval checktunnel" USR1 } runchecks () { if [ -f ${LOCK_DIR}/tunnel.pid ]; then OLD_PID=`cat ${LOCK_DIR}/vpnd.pid` if [ -d /proc/${OLD_PID} ]; then echo "vpnd is already running on process ${OLD_PID}." exit 1 else echo "removing stale pid file." rm -rf ${LOCK_DIR}/vpnd.pid echo $$ > ${LOCK_DIR}/vpnd.pid echo "checking tunnel state." eval checktunnel fi else echo $$ > ${LOCK_DIR}/vpnd.pid eval starttunnel fi } case $1 in check) if [ -d /proc/`cat ${LOCK_DIR}/vpnd.pid` ]; then kill -USR1 `cat ${LOCK_DIR}/vpnd.pid` exit 0 else echo "vpnd is not running." exit 1 fi ;; reset) if [ -d /proc/`cat ${LOCK_DIR}/vpnd.pid` ]; then kill -HUP `cat ${LOCK_DIR}/vpnd.pid` exit 0 else echo "vpnd is not running." exit 1 fi ;; --help | -h) echo "Usage: vpnd [ check | reset ]" echo "Options:" echo " check Sends running vpnd a USR1 signal, telling it to check" echo " the tunnel state, and restart if neccesary." echo " reset Sends running vpnd a HUP signal, telling it to reset" echo " it's tunnel connection." ;; esac ln -sf $ORIG_SSH $SSH settraps runchecks while true; do i=0 while [ $i -lt 600 ]; do i=((i+1)) sleep 1 done eval checktunnel done |
I actually run this setup on Pentium 90's running the LRP distribution of Linux. LRP is a distribution of Linux that fits in, and boots off of a single floppy disk. You can learn more about it at http://www.linuxrouter.org/ You can download my LRP package for the VPN client from here. You will also need both the ppp and ssh packages from the LRP site.
We will need a few pieces of software. Get the following packages, and install them where specified.
To start, you probably need to rebuild your kernel for the server. You need to make sure that the following kernel options are turned on in addition to basic networking and everything else that you might need. If you've never built your own kernel before, read the Kernel HOWTO.
For 2.0 kernels:
CONFIG_FIREWALL
CONFIG_IP_FORWARD
CONFIG_IP_FIREWALL
CONFIG_IP_ROUTER
CONFIG_PPP
For 2.2 kernels:
CONFIG_FIREWALL
CONFIG_IP_ADVANCED_ROUTER
CONFIG_IP_FIREWALL
CONFIG_IP_ROUTER
CONFIG_PPP
We first should configure the external interface of the server. You should already know how to do this, and probably already have it done. If you don't, then do so now. If you don't know how, go back and read the Networking HOWTO
Now we bring up the internal interface. According to the numbers that we've chosen, the internal interface of the server is 192.168.40.254. so we have to configure that interface.
For 2.0 kernels, use the following:
# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 192.168.40.255 # /sbin/route add -net 192.168.40.0 netmask 255.255.255.0 dev eth1 |
For 2.2 kernels, use the following:
# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 192.168.40.255 |
That gets our basic interfaces up. You can now talk to machines on both local networks that are attached to the server.
# /sbin/route add -net 192.168.0.0 gw 192.168.254.254 netmask 255.255.0.0 dev eth1 |
To set the rules with ipfwadm, run it like so:
# /sbin/ipfwadm -F -f # /sbin/ipfwadm -F -p deny # /sbin/ipfwadm -F -a accept -S 192.168.40.0/24 -D 192.168.0.0/16 # /sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16 # /sbin/ipfwadm -F -a accept -b -S 192.168.11.0/24 -D 192.168.0.0/16 |
To set the rules with ipchains, run it like so:
# /sbin/ipchains -F forward # /sbin/ipchains -P forward DENY # /sbin/ipchains -A forward -j ACCEPT -s 192.168.40.0/24 -d 192.168.0.0/16 # /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16 # /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.11.0/24 -d 192.168.0.0/16 |
/sbin/route add -net 192.168.11.0 gw 192.168.10.253 netmask 255.255.255.0 /sbin/route add -net 192.168.10.0 gw 192.168.11.253 netmask 255.255.255.0 |
Your options file should contain at least the following:
ipcp-accept-local ipcp-accept-remote proxyarp noauth |
The third line is very important. From the pppd man page:
proxyarp Add an entry to this system's ARP [Address Resolu- tion Protocol] table with the IP address of the peer and the Ethernet address of this system. This will have the effect of making the peer appear to other systems to be on the local ethernet. |
The following is what my /etc/sshd_config file looks like. Yours should look the same or similar:
# This is the ssh server system wide configuration file. Port 22 ListenAddress 0.0.0.0 HostKey /etc/ssh_host_key RandomSeed /etc/ssh_random_seed ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin yes IgnoreRhosts yes StrictModes yes QuietMode no FascistLogging yes CheckMail no IdleTimeout 3d X11Forwarding no PrintMotd no KeepAlive yes SyslogFacility DAEMON RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication no PermitEmptyPasswords no UseLogin no |
We're going to use a single home directory for all of the users. So just run:
# mkdir /home/vpn-users |
Now create the .ssh directory in the vpn-users home directory.
# mkdir /home/vpn-users/.ssh |
... nobody:x:65534:100:nobody:/dev/null: mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash joe:*:1020:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd bill:*:1020:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd frank:*:1020:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd ... |
You can also control which users are allowed to connect by modifying the /home/vpn-users/.ssh/authorized_keys file. If you remove the user's public key line from this file, they won't be able to log in.
Now we move onto the client. First we must rebuild the kernel so that it can support all of the functions that we need. The minimum requirement is to have ppp in the kernel. You will need forwarding, a firewall, and a gateway only if you are going to allow other machines access to the tunnel. For this example, I will setup one of the remote office machines in my example layout. Add the following options to your kernel. Again, if you've never built a kernel before, read the Kernel HOWTO.
For 2.0 kernels:
CONFIG_PPP
CONFIG_FIREWALL
CONFIG_IP_FORWARD
CONFIG_IP_FIREWALL
CONFIG_IP_ROUTER
CONFIG_IP_MASQUERADE
CONFIG_IP_MASQUERADE_ICMP
For 2.2 kernels:
CONFIG_PPP
CONFIG_FIREWALL
CONFIG_IP_ADVANCED_ROUTER
CONFIG_IP_FIREWALL
CONFIG_IP_ROUTER
CONFIG_IP_MASQUERADE
CONFIG_IP_MASQUERADE_ICMP
/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0 /sbin/route add -net 192.168.10.0 netmask 255.255.255.0 dev eth1 |
/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0 |
/sbin/ipfwadm -F -f /sbin/ipfwadm -F -p deny /sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16 |
/sbin/ipchains -F forward /sbin/ipchains -P forward DENY /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16 |
As root on the client, run the following lines:
# mkdir /root/.ssh # ssh-keygen -f /root/.ssh/identity.vpn -P "" |
1024 35 1430723736674162619588314275167.......250872101150654839 root@vpn-client.mycompany.com |
# ssh vpn.mycompany.com |
# /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish -i /root/.ssh/identity.vpn -l vpn-user vpn.mycompany.com > /tmp/vpn-device (now wait about 10 seconds) # /usr/sbin/pppd `cat /tmp/vpn-device` 192.168.10.254:192.168.40.254 |
Note the IP addresses specified on the pppd line. The first is the address of the client end of the tunnel. The second is the address of the server end of the tunnel, which is set to the server's internal address. If all of that seemed to work, move on. If not, check that you have all of the options, and that they are spelled right. If something is still going wrong, check Section 6.1.
Now set the route to send traffic through the tunnel. Just run this:
# /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 255.255.0.0 |
Use the vpnd script. Only you may need to modify it a little. Make the following changes:
Change the variables at the top to match your setup. Most should be just fine as they are, but you can change them should you need to.
Line 27: add the local and remote IP addresses before $PPP_OPTIONS
Line 31: Change this line, and the two after it to set routes for your internal nets.
Here are just a few of the snags that I've run into while using this system. I put them here so that you can hopefully avoid them. If you run into any new ones, please email them to me so that I can keep track, and help others avoid them.
I wonder however if there might be some pppd option that will fix this problem.
Also, if someone could help me refine my scripts (or even write an executable) that would help a lot. I'm not sure why, but even my own bash doesn't follow the rules and doesn't seem to interpret signals correctly. If you do make any improvements, please email me at matthew@shinythings.com.