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.
Note 2 added 4 May 2014
The description in this article refers to Debian. I'm now using ArchLinux as my standard distribution. I haven't needed to set up a vpn tunnel recently but a quick glance at the Arch documentation shows what seems to be a very similar method of doing so. See PPTP VPN client setup with pptpclient. The instructions in the Arch wiki are, as usual, excellent and should be easy to follow.
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 open. I describe these separately.
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. (Make sure you get this Howto - it's essential.) 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 (i.e. the name you made up).
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-screen 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 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".
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/messagesIf 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.
Apr 18 13:17:36 attica pppd: pppd 2.4.4 started by root, uid 0
Apr 18 13:17:36 attica pppd: Using interface ppp0
Apr 18 13:17:36 attica pppd: Connect: ppp0 <--> /dev/pts/4
Apr 18 13:17:37 attica pppd: CHAP authentication succeeded
Apr 18 13:17:37 attica pppd: MPPE 128-bit stateless compression enabled
Apr 18 13:17:39 attica pppd: local IP address 192.168.0.1
Apr 18 13:17:39 attica pppd: remote IP address xxx.xxx.xxx.xxx
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 at what you see for "inet addr" after running the ifconfig command. 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 ppp0This 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.
#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.