Here are my notes on setting up a tunnel router (to route between a house network and ted-williams.mit.edu) under Debian, using Openswan. (It is also possible to use racoon, but that involves some pain with X.509 certificates which no one seems to have quite figured out. So I used Openswan.) I have a router with two network wired interfaces, one for the outgoing cable-modem connection and one for my home network. This configuration has the known flaw that clients on the house network cannot exchange IP packets with the router machine using the router's MIT address. (They can talk through the router to outside hosts, and they can talk to the router using its Comcast IP address, and traffic for the latter does not appear to go through the tunnel.) 1. Installing Debian This was my first experience with Debian, so I'll include some general Debian notes as I go. If you're already familiar with Debian, you can ignore them. At the time I was doing this, the current stable Debian release (Woody) was pretty old, so I opted to install the testing release (Sarge). I grabbed the i386 netinst CD image from http://www.debian.org/devel/debian-installer/, burned it, booted it, and installed. I used debian.lcs.mit.edu as my mirror. (If you see debian.csail.mit.edu, that's a newer name for the same thing.) I opted to install the desktop environment, because it's difficult to reconfigure a tunnel on ted-williams.mit.edu without a graphical web browser. I wound up with a Linux 2.4 kernel, because that was the installer default. It's apparently possible to install a Linux 2.6 kernel using the "install26" boot command from the CD. But a 2.4 kernel works fine for this purpose. 2. Configuring network interfaces /etc/network/interfaces contains the network configuration. Your should look something like: auto lo iface lo inet loopback iface eth0 inet dhcp iface eth1 inet static address 18.101.0.161 netmask 255.255.255.240 broadcast 18.101.0.175 My machine actually has the complication that both network interfaces are PCMCIA cards, and aren't necessarily configured in a deterministic order. (Although they always do come up the same way, empirically.) The ifrename package is supposed to deal with this, but for now I've opted for the simpler route of using mappings: mapping eth0 eth1 script /etc/network/get-mac-address map 00:E0:98:7E:5D:7E comcast map 00:20:E0:0E:12:6B hub iface comcast inet dhcp iface hub inet static address 18.101.0.161 netmask 255.255.255.240 broadcast 18.101.0.175 where /etc/network/get-mac-address is copied from /usr/share/doc/ifupdown/examples/get-mac-address.sh. (Be sure to set the executable bit.) Only the ifup/ifdown scripts understand the mappings, so if you have this problem and you need to refer to an interface name for some reason, you'll need to use the ifrename package instead, or cheat by using the empirical order, or find some other way around the problem. 3. Configuring Openswan First, you'll need to fetch it, which is easy: "apt-get openswan". This will also create your private key. (Ask it to create just a private key, not a certificate, contrary to its recommendations.) Note that you do *not* need to patch your kernel or build any kernel modules to make openswan work, even though openswan has openswan-modules-source as a suggested dependency. /etc/ipsec.conf should contain something like (18.7.14.134 is ted-williams's IP address; 18.101.0.160/28 is my tunnel subnet): conn mit left=%defaultroute leftid=@naming-schemes.mit.edu leftsubnet=18.101.0.160/28 right=18.7.14.134 rightsubnet=0.0.0.0/0 rightid=@ted-williams.mit.edu rightrsasigkey=0x0103aead3e65edb074fd9477ae847ecf55630961e2d8232bd0b579c475192e1bd8c0df57cd416d3a53029167fc20dca2b2405d980c44f02aceb9afd4e6a6e37a72cecd6aa641c44c6ead97265c2d11ef9aac6d987ccf0f4bb62d54f6e7f78b0986e2aadfcc8db39d3878a31af71e31928859009097964e48b989d0c26c7a55ebe4c4b8c25467c2a2921a1e0a905de87ca937367ae938f411cd3fbf160c64bca93551ad6c8cfa59600278483c1b92de77222ed39f24eff502ec228a59a97e7fbbef77b0939ac98f30507cd59cba9414cb846a1bcf6657ee4027b91328f879d17d7ef8c9bc12bf7b1509f792916165cb31b4021b342ae5f0287a4f27449bfc4af8d109 auto=start 4. Enable IP forwarding: In /etc/sysctl.conf, add: net/ipv4/ip_forward=1 "sh /etc/init.d/procps.sh start" will propagate this setting. 5. Setting up the tunnel on ted-williams Connect to https://ted-williams.mit.edu/ with MIT certificates (fetched from https://ca.mit.edu/), change your tunnel type to ipsec if necessary, and feed it the public key value shown by: ipsec showhostkey --left (I saw an error message about being unable to route something. It seems to be harmless.) You should now be able to enable your tunnel with "/etc/init.d/ipsec start". 6. Set up MSS clamping Some people report that ipsec tunnels do not have MTU issues, but they do for me. To avoid path-MTU issues with your tunnel, you can turn on MSS-clamping with an iptables invocation. To make this happen at boot, create an /etc/init.d/mssclamp containing: #!/bin/sh case "$1" in start) iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \ --set-mss=1400 ;; esac (1400 is a value I chose after determining empirically that sending large TCP packets outbound seemed to succeed with the MSS clamped to 1404 or less, but fail with the MSS clamped to 1405 or more. I have no explanation. --set-mss=1480 or --clamp-mss-to-pmtu ought to work, and seems to for downstream packets.) Make the file executable and run "update-rc.d mssclamp defaults 25". "/etc/init.d/mss start" will enable mss-clamping for the running session. Note that AFS may still have MTU issues (supposedly fixed for Linux in OpenAFS 1.3.73), which will not be helped by MSS-clamping because AFS does not use TCP. So AFS-using clients may still need to set their interface MTUs down. 7. Set up traffic shaping If you use a cable modem, you may have noticed that when you use all your uplink bandwidth, your interactive performance goes to pot. This is probably due to a broken queueing implementation in the cable modem. You can correct for this problem by traffic-shaping your uplink bandwidth. Create an /etc/init.d/traffic containing: #!/bin/sh case "$1" in start) tc qdisc add dev eth1 root tbf rate 220kbit latency 50ms \ burst 1540 ;; esac "220kbit" should be a little less than your uplink bandwidth. Make the file executable and then run "update-rc.d traffic defaults 25". "/etc/init.d/traffic start" will enable traffic shaping for the running session.