Make sure you complete the first section before going on to any of the other sections:
PPTP-Client Setup/Configuration
Routing Script
Mounting Network Drive
Troubleshooting
I (Kevin) attend (at the time of the writing of this section) the University of Denver College of Law. The law school has a wireless network that I wanted to be able to use with my FreeBSD laptop. Using wireless in FreeBSD is a breeze--I use it all the time with Quest DSL. However, whereas our home network is secured by MAC address, the law school's wireless network is secured by a Microsoft VPN.
NOTE: We'll be doing everything in this section as "su".
The law school provides instructions for logging into the Wireless VPN here, but because the law school only supports Microsoft Windows XP (which technically all students are required to have, although we have a few "rebel" Mac-users and one even more rebellious FreeBSD-user), the instructions provided by the law school's computer help desk are only for logging in via Microsoft Windows XP. (Using the built-in Microsoft VPN Client).
Obviously this won't do, so our first task is to obtain a Microsoft-compatible VPN client for FreeBSD.
cd /usr/ports/net/pptpclient
make install clean
This will install PPTP-Client, a Microsoft-compatible VPN client. PPTP-Client is maintained by James Cameron, and for more information you can visit the PPTP-Client homepage here. PPTP-Client also has a mailing list, without which this guide would not have been possible. List members are generally very helpful (especially Mr. Cameron, who answers many of the posts himself), but keep in mind that most users/development is on Linux.
Now that we have a VPN Client, we have to configure it.
vi /etc/ppp/ppp.conf
PPTP-Client uses FreeBSD's user-ppp (this comes with FreeBSD so you don't have to install anything), which is what we are about to configure.
For the DU Law Wireless VPN, I use the following configuration in /etc/ppp/ppp.conf:
DULawWireless:
set authname USERNAME
set authkey PASSWORD
set timeout 0
set ifaddr 0 0
add 10.158.11.250/24 HISADDR
alias enable yes
disable ipv6cp
add default HISADDR
"DULawWireless" is just the name I gave to this particular pptp connection. You can call yours whatever you want, such as "office" or "school" or "vpn". Keep it reasonably short though because you'll be entering this name when you invoke pptp.
"USERNAME" and "PASSWORD" are pretty self-explanatory. At DU, they are the username and password you use to log into your e-mail account. You can get this information from your university or office.
"10.158.11.250/24" is the IP of the PPTP (VPN) Server. DU lists theirs as "10.158.11.250" here, but note that in /etc/ppp/ppp.conf I added "/24" to the end of the address. This is very important, as you won't be able to connect without this.
We now actually have enough set to log into the Wireless VPN, but we're not finished yet. The default behavior on Microsoft-VPNs is to route all network traffic through the tunnel interface. In order to do this, we'll have to do a little more work. . .
NOTE: I figured out what I needed to do to complete the connection and enable web-browsing, POP3/SMTP access, etc. with the help of James Cameron (who explained to me how the process works in Linux), and with the help of my friend Beth (who provided the "ipconfig /all" and "netstat -rn" output from her Windows XP laptop while she was logged into the Wireless VPN).
pptp 10.158.11.250 DULawWireless
We should now be logged onto the Wireless VPN. (You won't have a command prompt in your terminal window anymore. The VPN connection can be closed by selecting this terminal and hitting 'Ctrl+C'
Now, in a second terminal window, type the following:
ifconfig tun0
You should see something like this:
tun0: flags=8051
inet 130.253.171.135 --> 130.253.171.11 netmask 0xffffffff
Opened by PID 638
This is telling us that for the interface "tun0" (our tunnel into the Wireless VPN), our Gateway is "130.253.171.11" and the IP assigned to our computer by the PPTP Server is "130.253.171.135". This latter address will change every time we log into the VPN, so I will denote it as "130.253.171.xxx" from here on in order to avoid confusion.
Next, in the same terminal we just executed the "ifconfig" command in, type the following:
route change default 130.253.171.xxx
route add 130.255.255.255 130.253.171.xxx 255.255.255.255
route add 255.255.255.255 130.253.171.xxx 255.255.255.255
vi /etc/resolv.conf
When dhclient ran at system startup, we should have obtained an IP address from the DU Law Wireless DHCP Server. (NOT the PPTP/VPN Server). Our /etc/resolv.conf should have also been populated with the following:
search law.du.edu
nameserver 130.253.166.6
This won't get us very far. In fact, the only thing we'll see if we open Firefox and try to browse the web is the DU Law Insecure Wireless Connection Warning Page. (Not the most exciting thing in the world). 'Ping' will reach "130.253.166.6" and bounce back to us every time, no matter what DNS address we input.
The solution (which I learned from studying Windows XP's "ipconfig /all" output) is to manually change our nameserver(s). The correct /etc/resolv.conf should look like this:
search law.du.edu
nameserver 130.253.166.41
nameserver 130.253.166.42
Unfortunately, the good nameservers will be periodically overwritten with the worthless "130.253.166.6" nameserver, so for the sake of convenience we can add a line to /etc/dhclient.conf telling it not to overwrite our nameserver:
vi /etc/dhclient.conf
My /etc/dhclient.conf file looks like this:
# $FreeBSD: src/etc/dhclient.conf,v 1.3 2001/10/27 03:14:37 rwatson Exp $
#
# This file is required by the ISC DHCP client.
# See ``man 5 dhclient.conf'' for details.
#
# In most cases an empty file is sufficient for most people as the
# defaults are usually fine.
#
prepend domain-name-server 130.253.166.41;
This line tells dhclient to overwrite the bad nameserver provided by the DHCP server with the good nameserver we've manually entered.
Please note that this change will not take effect until you restart dhclient.
dhclient wi0
Where "wi0" is your wireless network interface. There, now you should be able to enjoy network/internet access without having your good nameserver overwritten every 30 minutes. (Please also note that the above command works to restart dhclient in FreeBSD 6.0. If you are running 5.x, restart dhclient with the distinctly more FreeBSD-like "/etc/rc.d/dhclient restart" command).
Obviously, when you're connecting to the wireless network at home or elsewhere, you don't want your top nameserver to be "130.253.166.41"; you want it to be whatever your ISP's DHCP Server designates. For the sake of convenience, you can just insert a "#" before the "prepend. . ." line in /etc/dhclient.conf to "comment out" that line. When you return to DU or wherever your Wireless VPN is, open /etc/dhclient.conf again and "uncomment" this line by deleting the "#" in front of it.
That should be it. Let's test out our connection to the internet:
root@fongsaiyuk# ping -c 3 www.yahoo.com
PING www.yahoo.akadns.net (66.94.230.51): 56 data bytes
64 bytes from 66.94.230.51: icmp_seq=0 ttl=50 time=42.160 ms
64 bytes from 66.94.230.51: icmp_seq=1 ttl=51 time=34.014 ms
64 bytes from 66.94.230.51: icmp_seq=2 ttl=50 time=30.561 ms
--- www.yahoo.akadns.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 30.561/35.578/42.160/4.863 ms
Great, we're connected! Open up Firefox, Gaim, Thunderbird, and/or whatever internet app you want to use. When you're finished using the internet, open up the original terminal window from which you invoked pptp and close the connection by hitting 'Ctrl+C'.
NOTE: I'm well aware that this probably isn't the simplest nor is it the most elegant way of logging into the Wireless VPN and routing all of our traffic through the VPN tunnel connection. It does, however, work, and right now that's all I need.
Laziness is the mother of all invention, or something like that. About 7 months after creating this page, I've finally created a script to automate the route-adding/changing portion of using a Microsoft VPN:
#!/bin/sh
i=`ifconfig tun0 | grep -w inet | awk '{print $2}'`
j=`echo $i | awk -F "." '{print $1}'`
route change default $i
route add $j.255.255.255 $i 255.255.255.255
route add 255.255.255.255 $i 255.255.255.255
exit 0
Although I have not had (and probably will not have) the opportunity to test this script on other Microsoft VPNs besides the DU Law Wireless VPN, it should work on VPNs that require similar routing behavior. If you want to try it out, paste this script into a new file ("vpn.sh" in the following examples). Make sure the script is executable:
chmod 755 vpn.sh
If you don't already have a ~/bin directory, create one, then put the script inside. This way it'll be in your path and you can run it from anywhere (even if you're root, which you have to be to run it).
In order to use this, you have to first log onto your VPN:
pptp 10.158.11.250 DULawWireless
Then, in a new terminal window, run the script:
vpn.sh
And last but not least, don't forget to change your nameserver in /etc/resolv.conf, and set /etc/dhclient.conf not to overwrite it.
Before you can mount your network drive, you must first be logged into the VPN (or be connected to the network via a wired connection). Let's make a directory to mount our DU Law network drive in:
mkdir /HDrive
chown reinholz /HDrive
Replacing reinholz with your user. To mount our network drive:
mount_smbfs -I 130.253.166.28 -W law //KReinholz07@students/KReinholz07$ /HDrive
After executing this command, you'll be prompted for your password. (It's the same as your e-mail password). Also, you'll obviously want to insert your DU Law username in place of mine.
In a perfect world, the above steps would have gotten you online courtesy of the DU Law Wireless VPN. However, things can and will go wrong, so I'm going to attempt to provide you with some (sub-par) troubleshooting help.
Although it probably goes without saying, the first thing you should do in the event of a problem is double-check to make sure you entered everything correctly. Leaving out a line while manually reconfiguring our routing tables could easily lead to trouble.I'm going to go through the steps I took to connect to the Wireless VPN again, this time giving you the output from my terminal window and not just the commands I entered to get online. . . You should see something similar.
root@fongsaiyuk# pptp 10.158.11.250 DULawWireless
Remember, we then opened a second terminal window before typing the following:
root@fongsaiyuk# ifconfig tun0
tun0: flags=8051
inet 130.253.171.135 --> 130.253.171.11 netmask 0xffffffff
Opened by PID 638
root@fongsaiyuk# route change default 130.253.171.135
route: writing to routing socket: Disc quota exceeded
change net default: gateway 130.253.171.135: gateway uses the same route
root@fongsaiyuk# route add 130.255.255.255 130.253.171.135 255.255.255.255
add net 130.255.255.255: gateway 130.253.171.135
root@fongsaiyuk# route add 255.255.255.255 130.253.171.135 255.255.255.255
add net 255.255.255.255: gateway 130.253.171.135
root@fongsaiyuk# vi /etc/resolv.conf
Then you would edit /etc/resolv.conf appropriately or, if you inserted the "prepend. . ." line in /etc/dhclient.conf, you could skip this step.
If you still can't get online, try the following:
netstat -rn
This will display your network routing tables. When properly connected to the VPN and able to access the internet, my routing tables look like this:
root@fongsaiyuk# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 130.253.171.135 UGS 2 1754 tun0
10.158.11/24 link#2 UC 0 0 wi0
10.158.11.60 00:90:96:c3:00:21 UHLW 0 1 wi0 1185
10.158.11.78 00:90:96:b4:42:f0 UHLW 0 3 wi0 1185
10.158.11.99 00:0b:cd:75:1a:f2 UHLW 0 15 wi0 1185
10.158.11.124 00:11:0a:81:32:db UHLW 0 15 wi0 1188
10.158.11.138 00:11:0a:81:59:ee UHLW 0 15 wi0 1185
10.158.11.145 00:0f:20:95:51:16 UHLW 0 1 wi0 1167
10.158.11.158 00:90:96:c3:89:5f UHLW 0 15 wi0 970
10.158.11.186 00:11:0a:81:5a:24 UHLW 0 16 wi0 1023
10.158.11.217 127.0.0.1 UGHS 0 0 lo0
10.158.11.250 00:06:5b:fd:e5:59 UHLW 0 95 wi0 1195
10.158.11.254 00:0b:fc:7b:9c:00 UHLW 0 0 wi0 981
10.158.11.255 ff:ff:ff:ff:ff:ff UHLWb 0 42 wi0
127.0.0.1 127.0.0.1 UH 1 155 lo0
130.253.171.11 130.253.171.135 UH 0 0 tun0
130.255.255.255/32 130.253.171.135 UGS 0 0 tun0
255.255.255.255/32 130.253.171.135 UGS 0 0 tun0
Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UH lo0
fe80::%lo0/64 fe80::1%lo0 U lo0
fe80::1%lo0 link#1 UHL lo0
fe80::%wi0/64 link#2 UC wi0
fe80::202:2dff:fe25:95e8%wi0 00:02:2d:25:95:e8 UHL lo0
ff01::/32 ::1 U lo0
ff02::%lo0/32 ::1 UC lo0
ff02::%wi0/32 link#2 UC wi0
ff02::%tun0/32 fe80::202:2dff:fe25:95e8%tun0 UC tun0
root@fongsaiyuk#
Your routing tables are going to look different, especially if you're trying to use my example setup to connect to a different Wireless VPN.
Details of my setup aside, you can always try some general troubleshooting. . .
ping -c 3 www.yahoo.com
You can type in any URL you want, but in this example we're trying to see if we can connect to Yahoo!
Obviously, if we're successful you'll see something like this:
root@fongsaiyuk# ping -c 3 www.yahoo.com
PING www.yahoo.akadns.net (66.94.230.51): 56 data bytes
64 bytes from 66.94.230.51: icmp_seq=0 ttl=50 time=42.160 ms
64 bytes from 66.94.230.51: icmp_seq=1 ttl=51 time=34.014 ms
64 bytes from 66.94.230.51: icmp_seq=2 ttl=50 time=30.561 ms
--- www.yahoo.akadns.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 30.561/35.578/42.160/4.863 ms
The most common error on the DU Law Wireless VPN is for the 'ping' packets to get trapped on the intranet at "130.253.166.6" and come back. Under this scenario, your 'ping' output would look very much like the successful ping above, except you'd be getting the same response no matter what URL you typed in:
root@fongsaiyuk# ping -c 3 www.yahoo.com
PING www.yahoo.com (130.253.166.6): 56 data bytes
64 bytes from 130.253.166.6: icmp_seq=0 ttl=62 time=5.034 ms
64 bytes from 130.253.166.6: icmp_seq=1 ttl=62 time=3.938 ms
64 bytes from 130.253.166.6: icmp_seq=2 ttl=62 time=3.731 ms
--- www.yahoo.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.731/4.234/5.034/0.572 ms
See the difference? We're not resolving anything. Opening Firefox will get us the DU Law Wireless Insecure Warning Page, not what we want.
If this is the problem, check /etc/resolv.conf again. Your nameserver(s) may have been overwritten with the wireless nameserver.
vi /etc/resolv.conf
You'll more likely than not see this again:
search law.du.edu
nameserver 130.253.166.6
Go ahead and erase the nameserver entry and input the following instead:
search law.du.edu
nameserver 130.253.166.41
nameserver 130.253.166.42
The second nameserver is really optional. Entering the first is sufficient. Now try pinging www.yahoo.com or whatever URL you tried again and see if you get a different result. You should be reaching an IP address that is DIFFERENT from 130.253.166.6! If you are successfully able to ping, try Firefox or your desired internet application again and see what happens. If you're using Firefox, you may have to hold in 'Shift' and hit the "Refresh" button to clear the DU Law Insecure Wireless Warning Page and get a real internet page.
If you did the "prepend. . ." trick in /etc/dhclient.conf, open that file now and double-check to make sure the line is uncommented. A real easy way to deny yourself internet access is to forget to uncomment that line after using the internet at home the night before.
Another common 'ping' error is the dreaded "host name lookup failure":
root@fongsaiyuk# ping -c 3 www.yahoo.com
ping: cannot resolve www.yahoo.com: Host name lookup failure
Again, check /etc/resolv.conf to make sure you have the correct nameserver. You can get this error either by having an invalid nameserver (did you make a typo while manually changing the nameserver?) or if you have no connection to the network/internet at all. If everything is in order with /etc/resolv.conf, you can always try a plain old "ifconfig" to make sure your wireless interface is associated with a wireless network at all:
ifconfig
That should display something like this:
lo0: flags=8049
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
wi0: flags=8843
inet6 fe80::202:2dff:fe25:95e8%wi0 prefixlen 64 scopeid 0x2
inet 10.158.11.232 netmask 0xffffff00 broadcast 10.158.11.255
ether 00:02:2d:25:95:e8
media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
status: associated
ssid "DU Wireless" 1:"DU Wireless"
stationname "FreeBSD WaveLAN/IEEE node"
channel 6 authmode OPEN powersavemode OFF powersavesleep 100
rtsthreshold 2312 protmode CTS
wepmode OFF weptxkey 1
tun0: flags=8051
inet 130.253.171.135 --> 130.253.171.11 netmask 0xffffffff
Opened by PID 638
Obviously you won't have a "tun0" interface if you're not connected to the VPN, and if you don't have a valid connection to the insecure wireless, you won't have an IP address and other information for "wi0". If you're not connected to the network at all, you might see something like this:
lo0: flags=8049
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
wi0: flags=8843
inet6 fe80::202:2dff:fe25:95e8%wi0 prefixlen 64 scopeid 0x2
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
ether 00:02:2d:25:95:e8
media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
status: no carrier
ssid ""
stationname "FreeBSD WaveLAN/IEEE node"
channel -1 authmode OPEN powersavemode OFF powersavesleep 100
rtsthreshold 2312 protmode CTS
wepmode OFF weptxkey 1
Note the all-telling "status: no carrier" line. This indicates that we are not connected to/associated with a wireless network. Now you get to do some even more basic troubleshooting to figure out why you don't have a network connection. This guide to accessing the internet through a Microsoft (PPTP) VPN assumes you have a wireless network card configured and working, so such troubleshooting is beyond the scope of this guide.
If you are connected to the wireless network but STILL can't get online, check your ppp log. You might not be properly connected to the Wireless VPN.To view your ppp log, type:
vi /var/log/ppp.log
Although I said at the beginning of the guide that you have to be 'su' for all of this, if you're not, you'll be denied access to the ppp log. Change to 'su' and try again. Your ppp log might be quite long, so scroll down to the most recent session. (The log makes note of the date and time of each connection). My most recent connection, which was successful, looks like this:
Feb 25 10:25:32 fongsaiyuk ppp[625]: Phase: Using interface: tun0
Feb 25 10:25:32 fongsaiyuk ppp[625]: Phase: deflink: Created in closed state
Feb 25 10:25:32 fongsaiyuk ppp[625]: Warning: The alias command is deprecated
Feb 25 10:25:32 fongsaiyuk ppp[625]: Phase: PPP Started (direct mode).
Feb 25 10:25:32 fongsaiyuk ppp[625]: Phase: bundle: Establish
Feb 25 10:25:32 fongsaiyuk ppp[625]: Phase: deflink: closed -> opening
Feb 25 10:25:32 fongsaiyuk ppp[625]: Phase: deflink: Connected!
Feb 25 10:25:32 fongsaiyuk ppp[625]: Phase: deflink: opening -> carrier
Feb 25 10:25:33 fongsaiyuk ppp[625]: Phase: deflink: carrier -> lcp
Feb 25 10:25:34 fongsaiyuk ppp[625]: Phase: bundle: Authenticate
Feb 25 10:25:34 fongsaiyuk ppp[625]: Phase: deflink: his = CHAP 0x81, mine = none
Feb 25 10:25:34 fongsaiyuk ppp[625]: Phase: Chap Input: CHALLENGE (16 bytes from WL
VPN)
Feb 25 10:25:34 fongsaiyuk ppp[625]: Phase: Chap Output: RESPONSE (USERNAME)
Feb 25 10:25:34 fongsaiyuk ppp[625]: Phase: Chap Input: SUCCESS (S=1048EA43824687EB
12141ED2B6435C45F264473A)
Feb 25 10:25:34 fongsaiyuk ppp[625]: Phase: deflink: lcp -> open
Feb 25 10:25:34 fongsaiyuk ppp[625]: Phase: bundle: Network
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: Caught signal 2, abort connection(s)
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: deflink: open -> lcp
Feb 25 11:25:19 fongsaiyuk ppp[625]: Warning: 0.0.0.0/0: Change route failed: errno
: Disc quota exceeded
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: bundle: Terminate
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: deflink: Disconnected!
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: deflink: Connect time: 3587 secs: 91483
659 octets in, 3598305 octets out
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: deflink: 58183 packets in, 50071 packets out
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: total 26507 bytes/sec, peak 165172 bytes/sec on Fri Feb 25 11:11:49 2005
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: deflink: lcp -> closed
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: bundle: Dead
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: Signal 15, terminate.
Feb 25 11:25:19 fongsaiyuk ppp[625]: Phase: PPP Terminated (normal).
That's a log of a one-hour connection to the internet during my Contracts 2 class. Note that I manually edited out my username and changed it to "USERNAME" under the "Chap Output: RESPONSE. . ." line in my ppp log.
Okay, so what if your log looks nothing like this? What if you were never able to establish a connection to the PPTP Server?
First off, try to figure out where things went wrong. Is ppp being challenged for a username? Is the PPTP Server accepting the username and password supplied by /etc/ppp/ppp.conf? Check to make sure you input your username and password correctly.
At one point, I was able to connect to the PPTP Server and login. It would accept my username and password, then it would freak out and disconnect me. Checking my ppp log revealed this ugly line:
Jan 13 10:26:02 bsd ppp[567]: Phase: deflink: IPV6CP protocol reject closes IPV6CP !
This meant that ppp was trying to use the IPv6 protocol (rather than the standard IPv4 that is currently used) and that the Microsoft PPTP Server didn't understand, freaked out, and disconnected me. The solution is to make sure you have this line in your /etc/ppp/ppp.conf:
disable ipv6cp
This tells ppp not to use IPv6. Maybe in a few years IPv6 will become the standard, but it's not yet and seems to do little more than cause trouble at present, especially when we're dealing with Microsoft.
I hope this has proven helpful, but the nature of troubleshooting is such that it's impossible to anticipate every problem that might arise for a user. (Remember, I told you up front that this was going to be a "sub-par" attempt at troubleshooting the PPTP connection). For more troubleshooting help, try the PPTP-Client troubleshooting page here. It's not FreeBSD-specific, but there is a wealth of very useful information that may help you solve your problem.