Accessing the Stevens Campus Network

over VPN with Linux


Please note that these instructions are now outdated. Stevens has upgraded to a VPN system based around Cisco technologies. The page remains here for reference purposes and as possible help for others connecting to Microsoft-based VPN solutions from Linux machines.

Stevens Campus IT provides access to the campus network exclusively via VPN. While many would like ssh access, the powers that be refuse. Unfortunately, they've failed to provide decent instructions for accessing the campus network from a computer running Linux. What little there is exists here (outdated, distro specific, and sans encryption). Windows documentation has been updated for the new VPN (with encryption) and is available here [PDF].

In the process of trying to gain reliable access to the campus network, I ran into a number of problems due to the configuration of the VPN server. After reaching out to Campus IT and failing to receive meaningful, timely responses, I worked things out on my own. Due to their indifference, I have chosen to document the proper setup here rather than offer Campus IT a How-To which they could distribute.

Basic requirements

To get started you'll need a few different things for compatibility with Stevens' VPN server.

  1. If your kernel version is below 2.6.15, upgrade it or patch it to add MPPE support.
  2. If your kernel version is >= 2.6.15 check for MPPE support:
    $ grep -e 'MPPE' /boot/config CONFIG_PPP_MPPE=m
    You should see either an 'm' or a 'y'.
  3. Install the PPTP client, preferably from your Linux distribution. If you need/want the source, the project is hosted at: http://pptpclient.sf.net/.
  4. A version of pppd newer than v2.4.2.

Configuration files

Once you have all of these setup. You'll need to edit a few files. For starters you'll need a /etc/ppp/chap-secrets containing the following line:

CAMPUS\\username PPTP campus-domain-passwd *
Of course you need to fill in your own username and campus domain password. Because this file contains your campus domain password, you should make sure that only root has permissions for the file.

In addition, you'll need to make sure the file /etc/ppp/options.pptp contains the following lines, and that they are uncommented:

lock noauth refuse-eap # refuse-chap # Disabling these three ensures use of MS-CHAPv2 auth refuse-mschap # nobsdcomp nodeflate

Finally, you'll need a file in the /etc/ppp/peers/ directory whose name will be the name of the connection as far as pppd is concerned. For our purposes, we'll use stevensvpn. If you choose to use a different filename, be sure to make the appropriate changes in the scripts below. The file should contain the following:

pty "pptp 155.246.151.11 --nolaunchpppd" name CAMPUS\\username remotename PPTP require-mppe-128 file /etc/ppp/options.pptp ipparam stevensvpn
Once again, you'll need to substitute your actual username on line 2.



Test your work

At this point, you're ready to test the connection. Running the following as root will allow you to see if the connection succeeds.

# pppd call stevensvpn debug dump logfd 2 nodetach
If all goes well, you should receive an IP address in the 155.246.152.xxx subnet. Once you see your IP address, press CTRL-C to close out the connection. If the connection fails, there could be several reasons.
  1. First, recheck all your configuration files. Also, make sure you have the correct password. Remember, your campus domain password is not necessarily the same as your Pipeline password unless you've set them that way.
  2. Second, your firewall/router/NAT may be messing up the connection. Make sure that it is configured to allow "established" connections over IP as well as TCP. This is required for the eGRE packets. Additionally, since eGRE doesn't have TCP's connection tear-down to inform the NAT tables that the connection is no longer in use, attempts to connect from different machines behind the NAT, within a short time period will fail due to the NAT continuing to send eGRE packets to the first machine.

Working around the Stevens misconfiguration

Now comes the fun part of this whole exercise. Up until now, the configuration has been fairly standard for a connection to a VPN that authenticates against a Microsoft Domain Controller. The problem is that when pptpclient establishes the connection, it doesn't receive a proper address for the other end of the tunnel. By default it sets up the interface (typically ppp0) as point-to-point between the 155.246.152.xxx client address you received, and the 155.246.151.11 server address. This causes all traffic destined for the VPN server, including the packets that are supposed to tunnel the VPN traffic, to be sent over the VPN interface. This creates a nasty little routing loop that spikes CPU usage to 100%.

Luckily the solution to this is quite simple (once you know the correct configuration). The loop route must be removed, and a route to the desired portion of the campus network must be setup using your client address as the gateway and the VPN interface as the device. For example:

# route del -host $VPN_SERVER dev $VPN_INTF # route add -net $VPN_NETWORK netmask $VPN_NETMASK \ gw $INT_IPADDR dev $VPN_INTF

Putting it all together

It is my philosophy that since computers are primarily designed for programmatically repeating tasks, I should never have to do more than issue a single command for anything I will do more than once. As such, I've whipped up a small shell script to handle connecting to the Stevens VPN. Hopefully you'll get some mileage out of it too.

stevensvpn.sh (download)
#!/bin/bash # Connection script for Stevens Inst. of Tech. VPN (Campus Domain Auth) # http://www.coglib.com/~jcordasc/onsite/stevensvpn.sh # Copyright (c) 2008 Jared Cordasco (jcordasc@coglib.com) # All rights reserved. # # Redistribution and use of this script, with or without modification, is # permitted provided that the following conditions are met: # # 1. Redistributions of this script must retain the above copyright # notice, this list of conditions and the following disclaimer. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR ''AS IS'' AND ANY EXPRESS OR IMPLIED # WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO # EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, # SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, # PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; # OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, # WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR # OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # # Interface created by pppd for vpn traffic # VPN_INTF=ppp0 # # IP address of the vpn server # VPN_SERVER=155.246.151.11 # # First three octets of subnet on which the client is assigned an address # (NOTE: This is used for determining the internal IP address assigned to # the client. Due to this, it must be a string of the form: # xxx.yyy.zzz in order to work.) # INT_SUBNET=155.246.152 # # Network and netmask describing which traffic should be routed over the # vpn connection. # VPN_NETWORK=155.246.0.0 VPN_NETMASK=255.255.0.0 # # pppd profile correctly configured for vpn (found in /etc/ppp/peers/) # PPPD_PROFILE=stevensvpn # # Amount of time to sleep waiting for vpn connection to complete # SLEEP=5 ### Do not edit below this line ######################################### PATH=$PATH:/sbin:/usr/sbin ROUTE_INFO=$(route -n | egrep -e '^0.0.0.0' | awk '{print $2 ":" $8}') DFLT_GWY=${ROUTE_INFO%%:*} EXT_INTF=${ROUTE_INFO##*:} start_vpn() { ROUTE_INFO=$(route -n | egrep -e "^$VPN_SERVER" | \ awk '{print $2 ":" $3 ":" $8}') if [ "$ROUTE_INFO" != "$DFLT_GWY:255.255.255.255:$EXT_INTF" ] ; then echo -n "Adding route to VPN server ... " route add -host $VPN_SERVER gw $DFLT_GWY dev $EXT_INTF echo "Done." fi echo -n "Starting pppd ... " pppd call $PPPD_PROFILE echo "Done." echo -n "Waiting $SLEEP seconds for connection ... " sleep $SLEEP echo "Done." ifconfig $VPN_INTF > /dev/null 2>&1 EXIT="$?" while [ "$EXIT" != "0" ] ; do echo " Connection not up." echo -n " Waiting $SLEEP seconds for connection ... " sleep $SLEEP echo "Done." ifconfig $VPN_INTF > /dev/null 2>&1 EXIT="$?" done INT_IPADDR=$(ifconfig $VPN_INTF | \ sed -ne "/P-t-P/ { s/^.*\\($INT_SUBNET.[^ ]*\\).*$/\\1/ ; p }") echo -n "Deleting loop route ..." route del -host $VPN_SERVER dev $VPN_INTF echo "Done." echo -n "Adding route to $VPN_NETWORK/$VPN_NETMASK ..." route add -net $VPN_NETWORK netmask $VPN_NETMASK \ gw $INT_IPADDR dev $VPN_INTF echo "Done." } stop_vpn() { echo -n "Killing pptp ... " killall -15 pptp echo "Done." ROUTE_INFO=$(route -n | egrep -e "^$VPN_SERVER" | \ awk '{print $2 ":" $3 ":" $8}') if [ "$ROUTE_INFO" == "$DFLT_GWY:255.255.255.255:$EXT_INTF" ] ; then echo -n "Removing route to VPN server ... " route del -host $VPN_SERVER gw $DFLT_GWY dev $EXT_INTF echo "Done." fi } usage() { echo -e "Usage:\n\t$(basename $0) <start|stop>\n" exit 1 } if [ "$(id -u)" != 0 ] ; then echo -e "\n*** Script must be run as root ***\n" exit 2 fi if [ -z "$1" ] ; then usage fi case "$1" in start) start_vpn ;; stop) stop_vpn ;; *) usage ;; esac

Additional notes

While quickly connecting to the Stevens VPN is relatively easy if you need access intermittently, for those who need more regular access or concurrent access from multiple machines on the same LAN, it can be very helpful to setup your firewall/router/NAT box to connect to the VPN and masquerade all LAN traffic destined for the campus network to the VPN.

There are a few small sticking points which I'll point out here. First, you will need to determine which traffic to NAT over the VPN interface. To make all campus connections over the VPN you would instruct iptables with the following command:

# iptables -t nat -I POSTROUTING -d 155.246.0.0/16 \ -o $VPN_INTF -j MASQUERADE
Note the use of the -I flag instead of the -A flag. This inserts the rule as the first rule in the POSTROUTING chain, rather than appending it to the end of the chain. This is very important as most NAT setups already have a rule to forward 0.0.0.0/0 over the default external interface. Unless the VPN rule preceeds this, no traffic will ever be directed over the VPN.

Additionally, due to the many networks that are being traversed, packet size can become a problem since the MTU/MRUs for the different networks are only slightly different. As of June 2008, these problems will crash the pptpclient daemon. To ensure this doesn't happen we have to use the NAT box to regulate MTU/MRU negotiation. The details are beyond the scope of this page. All you need to know is that with iptables, this can be setup with the following:

# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu

Don't forget to protect yourself from the wild and wooly world on the other side of the VPN connection. Something like this should be suitable.

# iptables $FLAG INPUT -i $VPN_INTF -m state \ --state ESTABLISHED,RELATED -j ACCEPT # iptables $FLAG INPUT -i $VPN_INTF -p tcp --dport 22 -j ACCEPT # iptables $FLAG INPUT -i $VPN_INTF -p udp --dport 22 -j ACCEPT
With that and an automated ping every so often (via cron) to some machine on campus, you should have a stable and convenient tie-in to the campus network.



NOTE: I am unaware of any Campus IT policy forbidding someone from maintaining a more or less persistent VPN connection. That said, the above technique is to be used at your own risk.