Hack 68. Connect to a Microsoft PPTP VPN
At home you are running the "One True" operating system, but at work you are languishing in a solid Microsoft shop. Your business is so far into the Microsoft camp that, horror of horrors, it has chosen to protect network access using a Microsoft VPN server. It won't even allow an SSH connection, which means you can't use port forwarding in SSH to access internal resources [Hack #75] . As a Linux user, you can use the plentiful open source tools to access your work email and files, and even remotely control your desktop PC. All that is stopping you from this computing-at-home nirvana is being able to connect to the existing Microsoft VPN server.
To connect and make your work machine available at home, you need to install some software known as PPTP Client. This package allows a Linux system to connect to a Microsoft PPTP VPN. The project is hosted at http://pptpclient.sourceforge.net/, but you might find the software is already available in your current distribution. The project web site has details on how to install the software if your distribution does not include it.
Using this information, you can start editing the configuration files. Fire up your favorite text editor, create a file called /etc/ppp/peers/office, and insert the username and the options file that contains your PPP configuration to use (options.pptp). As an example, you could have a file with the following settings:
# PPTP Tunnel configuration for tunnel office # # Specify our login username (may need to be domain\\username) # name username # # get all other options from the file /etc/ppp/options.pptp # file /etc/ppp/options.pptp
Depending on the VPN server you are connecting to, you might have to change username to domain\\username, where both values are replaced with the information your network administrator gives you. Next, edit the /etc/ppp/options.pptp file, which should contain the following:
# # Lock the port # lock # # We don't need the tunnel server to authenticate itself # noauth # # Turn off transmission protocols we know won't be used # nobsdcomp nodeflate # # We want MPPE # require-mppe
If your kernel does not already support it, you also need MPPE support to be built-in. Run this command as root:
foo@bar:~# modprobe ppp-compress-18
If the module loads without error, everything is well; otherwise, you need to obtain or build the ppp_mppe kernel module. If you are using a stock distribution kernel, this could be as simple as installing the required package. If a package isn't available, you need to build a custom kernel. The required kernel option (using menuconfig) is Network Device SupportPPP (point-to-point protocol) SupportPPP MPPE Compression (encryption).
You also need to use Version 2.4.2 or above of the ppp package. Now you need to edit the /etc/ppp/chap-secrets file to contain the following:
## OUTBOUND CONNECTIONS username "*" password
Again, you should replace both username and password with the values your network administrator gives you. If you are running a firewall at your end (you should be!), you need to configure the firewall to allow all packets out on TCP port 1723 to the VPN server. This is used to negotiate the connection and to pass link control traffic. The only other change that is required is to allow all GRE protocol packets (protocol number 47) between the client system and the VPN server. You should do this for both inbound and outbound traffic.
8.15.2. Starting the VPN
Now everything should be ready to go. To make a connection, log in as root and run the following command:
foo@bar:~# pptp-command start office Using interface ppp0 Connect: ppp0 <--> /dev/pts/1 MPPE 128-bit stateless compression enabled Cannot determine ethernet address for proxy ARP local IP address www.vvv.xxx.yyy remote IP address www.vvv.xxx.zzz pptp-command: added route add default dev ppp0 Tunnel office is active on ppp0. Local IP Address: www.vvv.xxx.yyy
Now try pinging a server on the remote end, which should give a result similar to the following:
foo@bar:~# ping -c 1 www.vvv.xxx.aaa PING www.vvv.xxx.aaa (www.vvv.xxx.aaa) 56(84) bytes of data. 64 bytes from www.vvv.xxx.aaa: icmp_seq=1 ttl=126 time=45.8 ms --- www.vvv.xxx.aaa ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3002ms rtt min/avg/max/mdev = 42.745/45.541/48.479/2.052 ms
OK, so now you should have a working connection to the office VPN server (and the office LAN), so what are you going to do with it? Perhaps the simplest thing to do now is to launch your favorite web browser, and point it at the company's intranet server. If you have a Microsoft Exchange server, try pointing your web browser at http://mailserver/exchange, where mailserver is the actual name of your Exchange server. Then you should be able to log in with your username and password and access your email. Alternatively, you can set up the email client on your Linux machine to pull mail from your corporate mail server, or you can access your work machine via RDP if it is a Windows XP desktop, or VNC if it is anything else [Hack #30] . Basically, once you have a VPN connection to your corporate network, you can do anything you would do at work, just a little more slowly.
It is important to remember that all packets passing over the VPN are encrypted, which introduces a bit of latency. This does not normally present a problem with most applicationse.g., web, email, file transfers. Some applications, such as Voice over IP, will be affected by this latency and will require careful tuning to operate successfully.