HOW TO SET UP A PPTP VPN TUNNEL IN DEBIAN
(Revised 26 July 2011)
Note added 19 February 2012
Once you have set up your tunnel in the way described here you will not
need to go through all these steps each time you connect on subsequent
occasions. All you need to do is described here.
Introduction
In April 2010 I needed to set up a "tunnel" (i.e. a link or connection)
to be able to use a proxy vpn server in the UK when I am abroad. This is
apparently a trivial task for users of Windows or the Apple Mac but a
search on Google quickly showed that this was not the case for Linux. I
found numerous pages offering advice on how to do it but wide variations
in the actual recommendations.
When I started trying to set things up myself I ran into all kinds of
problems. I normally use Debian, but most of the advice I found on the
Internet was for Ubuntu, which is similar but not identical to Debian.
Much of the Debian-related stuff was concerned with setting up a vpn
server, whereas what I needed was information about a vpn
client. Ubuntu seemed more relevant to the client aspect, so I
installed Ubuntu on a spare segment of my hard disk and tried out the
vpn instructions, using the graphic setup screen in Gnome. Although it
was quite easy to do this I wasn't left with a functioning tunnel so I
went back to Debian.
It took me 3 days to get vpn up and running. As usually happens, it was
quite a simple procedure in the end, but there were numerous
difficulties to get round on the way. I found the
solutions to these from various sources and sometimes just by trial and
error. It was an interesting learning experience but hard work.
I thought it might be useful to describe what I did. It may help some
users of Debian and Ubuntu and perhaps users of other Linux flavours as
well, though I don't know how far my approach would be applicable to
those.
Warning: please note that the server I was trying to reach uses
pptp for its vpn. Others use different forms of vpn and those would
need a different method from that described here. So this is not
supposed to be a comprehensive guide to setting up a vpn client on
linux. In fact, I don't think such a thing exists - there are too many
variations.
Another warning: I was trying to set up a tunnel to use a remote
server, not to access a remote site to read or upload files. I know some
people will need to do that, perhaps to reach their work site from home.
My method could no doubt be adapted for that purpose, but this isn't
what I was doing.
In what follows I don't describe all the false trails I followed but
I do indicate places where special care is needed. These are identified as
Tips.
I found there were two stages in getting vpn to work: 1. connecting to
the server and 2. arranging to route all traffic through the server once
the tunnel was up and running. I describe these separately.
A. Setting up the tunnel
Step 1. Install the Debian package pptp-linux (remember this is
for a pptp version of vpn).
Tip 1. This package includes pptpsetup, which is a
command-line facility to let you configure the tunnel, Its man
page gave me a link to an invaluable resource, the
Debian Howto for setting up a pptp client. (This in
turn provides links to how to debug things and a page giving
advice for when things go wrong, which fortunately I didn't
need.)
Step 2. You need to write various files in /etc/ppp. You can do
this automagically with pptpsetup, which often works brilliantly. If
not, you can edit the files by hand. following the instructions in the
Howto. Most are self-explanatory (but see Tip 2 below.) You have to
make up a name for the tunnel you are creating (e.g. vpn1 or whatever
you like). I didn't need to bother with the authentication domain name
because it wasn't relevant to what I was doing; you might need it if you
were accessing, say, your employer's site.
Tip 2. When editing /etc/ppp/peers/your-tunnel-name, the Howto
says you should put PPTP for 'remotename'. This isn't very clear; what
you need to put here is the tunnel-name itself.
Tip 3. Many servers don't want EAP (Extensor Authentication
Profile). To disable this, put "refuse-eap" in
/etc/ppp/peers/your-tunnel-name (without the quotes, of course).
Tip 4. If the server wants MPPE security (it probably does), put
"require-mppe-128" in the above file.
Step 3. Now that it's all set up correctly (you hope), it's time
to try it out. As root, type "pon your-tunnel-name". Note that you will
get no indication on-sceen about whether you have succeeded or not.So
you will need to do further tests, starting with Step 4.
Tip 5. If you try to do this without being root you will be told
you must add yourself to the dip group to be able to run it as non-user.
Don't do this: pon won't complain but your server won't come up.
Step 4. Do "ifconfig". If the pppd daemon is running the last entry will
begin "ppp0".
Shortcut: If this works, you could omit the remaining steps
in this section and go straight to Sending all traffic through the
network. If that doesn't work you will have to go through all the
steps in this section to try to find out what is wrong.
Step 5. Do "ps ax | grep pppd". This is another way of seeing if the daemon
is running.
Step 6. Do (as root) "tail /var/log/messages". This is a critical test. If
you have succeeded in connecting you should see something like this.
attica:~:# tail /var/log/messages
Apr 18 13:17:36 attica pppd[5118]: pppd 2.4.4 started by root, uid 0
Apr 18 13:17:36 attica pppd[5118]: Using interface ppp0
Apr 18 13:17:36 attica pppd[5118]: Connect: ppp0 <--> /dev/pts/4
Apr 18 13:17:37 attica pppd[5118]: CHAP authentication succeeded
Apr 18 13:17:37 attica pppd[5118]: MPPE 128-bit stateless compression
enabled
Apr 18 13:17:39 attica pppd[5118]: local IP address 192.168.0.1
Apr 18 13:17:39 attica pppd[5118]: remote IP address xxx.xxx.xxx.xxx
If you see something different, check the files you made in /etc/ppp for
possible typos etc. Make sure that /etc/ppp/peers/your-tunnel-name has
entries for "refuse-eap" and "require-mppe-128" if needed. If no luck
there, see the Howto for advice on enabling debug mode and diagnosing
problems.
B. Sending all traffic through the tunnel
Now that you've set up your tunnel, the next task is direct all your
traffic through it. This is the part it took me a long time to learn how
to do, but it's actually quite simple.
Step 7. Do "ip route show" with the tunnel
open. This will produce something like this.
attica:~:$ ip route show
xxx.xxx.xxx.xxx via 192.168.0.1 dev eth1 src 192.168.0.8
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.8
xxx.xxx.xxx.xxx dev eth0 proto kernel scope link src xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx dev eth1 scope link metric 1000
default via 192.168.0.1 dev eth1
default dev eth0 scope link metric 1000
The top line contains the IP for the vpn server but we are
not actually sending traffic through it yet. This is shown by the last
but one line, which tells us that the default gateway is 192.168.0.1
(the local gateway). We need to change this in Steps 8 and 9.
Step 8. Do (as root) "route del default". This will remove the
default local gateway.
Step 9. Do (as root) "route add default gw xxx.xxx.xxx.xxx" (set
up the remote gateway).
Tip 6. Very important: DON'T use the IP that was given
to you as the IP of your server. Instead, look at the LAST LINE
of /var/log/messages or look at what you see for "inet addr" in
ifconfig . Use this IP. Note that this IP is assigned
dynamically so may differ slightly each time you connect to the
server.
Step 10. If you now do "ip route show" you will see that the last
line reads:
default via xxx.xxx.xxx.xxx (the remote gateway) dev ppp0
The last line tells us things are working as expected.
Step 11. If you point your browser at a site that tells you what
your IP is, such as whatismyip.com, you should see the remote server
instead of your usual IP. This indicates that you are now accessing the
internet via the proxy vpn server
Tip 7. If you are running a firewall it may prevent you from
accessing any sites with your browser. Either turn the firewall off or
modify it. I use shorewall and was able to make things work by adding a
line for ppp0 in /etc/shorewall/interfaces.
################################################################
# Shorewall version 4.0 - Sample Interfaces File for one-interface
configuration.
# Copyright (C) 2006 by the Shorewall Team
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# See the file README.txt for further details.
#------------------------------------------------------------------------------
# For information about entries in this file, type "man
shorewall-interfaces"
#
# For additional information, see
# http://shorewall.net/Documentation.htm#Interfaces
#
###############################################################################
#ZONE INTERFACE BROADCAST OPTIONS
net eth1 detect
dhcp,tcpflags,logmartians,nosmurfs
net ppp0 detect
dhcp,tcpflags,logmartians,nosmurfs #added line for
ppp0
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
##########################################################
Tip 8. If you are using Firefox as your
browser you may find that it now says it can't find any page you point
it to. This seems to happen if Firefox wasn't running when you did all
the above stuff. I am told that you can make it work by going to
File/Work offline and enabling and then disabling that option.
Alternatively, just stop and restart Firefox.
The steps I have described here work for me. YMMV of course, but feel
free to email me if you want to know more: acATacampbell.org.uk.
I'm grateful to everyone who has provided suggestions that helped
me eventually to find my way through the thickets.
HOME | BACK
|