If you're reading this, then you likely need to connect to your office network from home or during travel. Many companies utilize Cisco 3000 vpn concentrators for their vpn needs, and I am willing to bet that most Linux newbies think that they are forced to use Windows to connect to them. Well I'm here to tell you that connecting to a Cisco vpn may very well be possible, and this document will hopefully enable to you to setup a working tunnel using your Gentoo workstation or laptop.
The assumptions made at this point are:
In order for the Linux to be able to open a vpn connection, "Universal TUN/TAP device driver support" must be enabled in the kernel. What is it, and why do we need it? Below is a relatively strait forward explanation from the kernel configuration dialog:
TUN/TAP provides packet reception and transmission for user space programs. It can be viewed as a simple Point-to-Point or Ethernet device, which instead of receiving packets from a physical media, receives them from user space program and instead of sending packets via physical media writes them to the user space program. When a program opens /dev/net/tun, driver creates and registers corresponding net device tunX or tapX. After a program closed above devices, driver will automatically delete tunXX or tapXX device and all routes corresponding to it.
You can verify if your kernel has TUN/TAP support with the following command:
# cat /usr/src/linux/.config | grep TUN CONFIG_INET_TUNNEL=m # CONFIG_INET6_TUNNEL is not set # CONFIG_IPV6_TUNNEL is not set CONFIG_TUN=m # CONFIG_8139TOO_TUNE_TWISTER is not set
As you can see above,
TUN/TAP support is located under: Device Drivers ---> Networking support ---> Universal TUN/TAP device driver support
If you already have TUN/TAP support built for your kernel, or you just booted your computer after a fresh kernel build, then we need to verify that the kernel has the appropriate code initialized.
If you built TUN/TAP support directly into the kernel, you should see
information from
# dmesg | grep TUN Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
If you build TUN/TAP support as a module, you first must load the "tun" module.
# modprobe tun # lsmod Module Size Used by tun 7296 0 nvidia 4050204 12
Now that the "tun" module is loaded, check dmesg output. You should see something like the following:
# dmesg | grep TUN Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
Now that we have a working kernel setup, we need to install vpnc.
# emerge net-misc/vpnc
In order to make the following sections more clear, we need an example setup to work from. For the purposes of this exercise, we will assume that we have a home network of several computers. All computers are on the 192.168.0.0 / 255.255.255.0 network. The lan in question is run by a Gentoo box running an iptables firewall / dhcp / caching dns / etc ..., and it masquerading the lan behind the public ip address it receives from an ISP. We now have a workstation on the lan that we want to be able to vpn into our office with.
Our workstation configuration looks like the following
# cat /etc/resolv.conf nameserver 192.168.0.1
# cat /etc/hosts 127.0.0.1 desktop localhost 192.168.0.1 router 192.168.2.2 mediacenter
# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:11:2F:8D:08:08 inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::211:2fff:fe8d:808/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3657889 errors:0 dropped:0 overruns:0 frame:0 TX packets:2305893 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2193722103 (2092.0 Mb) TX bytes:1415104432 (1349.5 Mb) Interrupt:185 Memory:fac00000-0 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:35510 errors:0 dropped:0 overruns:0 frame:0 TX packets:35510 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16023838 (15.2 Mb) TX bytes:16023838 (15.2 Mb)
# netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 loopback desktop 255.0.0.0 UG 0 0 0 lo default router 0.0.0.0 UG 0 0 0 eth0
Now that we have vpnc installed, and we have an example to work from, lets
discuss the basics of setting up vpnc. The configuration file for vpnc
connection settings can be located in a couple places, depending on how many
"profiles" you want to setup. By default, vpnc looks first for
# cat /etc/vpnc.conf IPSec gateway vpngateway.domain.org IPSec ID group_id IPSec secret group_password Xauth username network_signon Xauth password network_password
The config file example above should be modified to reflect the appropriate
values for your setup. The gateway option
If you are forced to export your profile from a Windows machine, then what you
will likely have is a file ending in
# cat example.pcf [main] Description= Host=VPNGATEWAY.DOMAIN.ORG AuthType=1 GroupName=group_id GroupPwd= enc_GroupPwd=F3256220AA200A1D532556024F4F314B0388D48B0FBF2DB12 EnableISPConnect=0 ISPConnectType=0 ISPConnect=FOOBAR ISPCommand= Username= SaveUserPassword=0 UserPassword= enc_UserPassword= NTDomain= EnableBackup=0 BackupServer= EnableMSLogon=1 MSLogonType=0 EnableNat=1 TunnelingMode=0 TcpTunnelingPort=10000 CertStore=0 CertName= CertPath= CertSubjectName= CertSerialHash=00000000000000000000000000000000 SendCertChain=0 VerifyCertDN= DHGroup=2 ForceKeepAlives=0 PeerTimeout=90 EnableLocalLAN=0 EnableSplitDNS=1 ForceNetLogin=0
In the above example, we can see entries for "Host","GroupName", and "enc_GroupPwd". Your "Username" and "UserPassword" may or may not be exported, depending on the setup.
Now that we have our configuration in place, its time to test our setup. To startup vpnc you do the following:
# vpnc-connect Enter password for username@vpngateway.domain.org: VPNC started in background (pid: 14788)...
As you can see from the above command output, once you type
# ifconfig -a eth1 Link encap:Ethernet HWaddr 00:11:2F:8D:08:08 inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::211:2fff:fe8d:808/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2101119 errors:0 dropped:0 overruns:0 frame:0 TX packets:1577559 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1757862627 (1676.4 Mb) TX bytes:732200131 (698.2 Mb) Interrupt:177 Memory:faa00000-0 sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.160.42 P-t-P:192.168.160.42 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1412 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:60 (60.0 b) TX bytes:616 (616.0 b)
# netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface vpn01.domain.or router 255.255.255.255 UGH 1500 0 0 eth1 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 loopback desktop 255.0.0.0 UG 0 0 0 lo default * 0.0.0.0 U 0 0 0 tun0
# cat /etc/resolv.conf nameserver 192.168.0.1
As you can see from the above command output(s), vpnc has done the following:
At this point, our workstation is capable of communicating with hosts via the
vpn, but only by ip address. As you have probably noticed, vpnc did not alter
our
Additional things we would like to have:
When you are ready to end the vpn session, execute
# vpnc-disconnect Terminating vpnc daemon (pid: 26250)
Unfortunately,
The ideal setup would allow us seperate our dns queries into two categories, vpn-related, and other. Under this setup, all vpn-related dns queries would be answered by dns servers located at the other end of our vpn tunnel, and all other queries would continue to be answered by local or ISP supplied dns servers. This is the setup that will be demonstrated here.
So how do we set things up, so that only requests made to hosts on the
example.org domain get sent to vpn supplied dns servers? Well, we're going to
need to install a local dns server, but don't worry, its much easier than you
think. There are several software packages that can handle the type of setup
we desire, but for the purposes of this demonstration,
# emerge -pv dnsmasq These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] net-dns/dnsmasq-2.22 0 kB # emerge -v dnsmasq
Now we need to add an option to our dnsmasq startup options. Edit the following option to suit your needs. Substitute .example.org with the appropriate domain, and the ip address with a valid dns server that belongs to the vpn tunnel.
# cat /etc/conf.d/dnsmasq # Config file for /etc/init.d/dnsmasq # See the dnsmasq(8) man page for possible options to put here. DNSMASQ_OPTS="-S /.example.org/192.168.125.10"
Now we need to make sure that the first entry in
# cat /etc/resolv.conf nameserver 127.0.0.1 nameserver 192.168.0.1
Now that we have setup a rule for our vpn tunnel dns, we need to startup dnsmasq.
# /etc/init.d/dnsmasq start
# rc-update add dnsmasq default
The ideal senario would be if only the traffic destined for vpn tunnel would travel accross the link. At this point, we have a vpn tunnel setup and all traffic will travel accross the tunnel, unless we specify additional routes. In order to fix this situation we need to know what networks are available to us on our vpn. The easiest way to find out the needed information is to ask a network administrator, but sometimes they are reluctant to answer such questions. If your local network admin wont volunteer the needed information, a little trial and error experimentation will be required.
When the vpn tunnel was started, vpnc set the default route to the tunnel. So we must set our default route back to normal, so that things work as expected.
# route add default gw 192.168.0.1
Earlier, when dns services were being configured for our vpn, we specified a dns server to handle our example.org domain. We need to add a route for the 192.168.125.0 subnet so that dns queries will work.
# route add -net 192.168.160.0 netmask 255.255.255.0 dev tun0
At this point, you should add any additional routes for known networks. If your friendly co-worker the network administrator gave you the required info, great. Otherwise, you might need to ping hosts you will be connecting to frequently, to give yourself an idea about what your routing table should look like.
# ping intranet1.example.org PING intranet1.example.org (172.25.230.29) 56(84) bytes of data. --- intranet.example.org ping statistics --- 18 packets transmitted, 0 received, 100% packet loss, time 16997ms
As you can see from the above example, we tried to ping host intranet1.example.org and were unsuccessfull. So we need to add a route for that subnet.
# route add -net 172.25.230.0 netmask 255.255.255.0 dev tun0
A few ping commands, and a few route commands later, you should be well on your way to a pretty good routing table.
Here is a script example to manage the vpn connection. You could execute it (as root) from an xterm to start a connection to your vpn. Then all you have to do is press return to disconnect the vpn. Obviously you will need to modify this for your setup, remembering to add all the additional routes that you may need.
# cat vpn.sh vpnc-connect route add default gw 192.168.0.1 route add -net 172.25.230.0 netmask 255.255.255.0 dev tun0 route add -net 192.168.160.0 netmask 255.255.255.0 dev tun0 route add -net 192.168.125.0 netmask 255.255.255.0 dev tun0 echo "press any key to disconnect ..." read $disconnect vpnc-disconnect route add default gw 192.168.0.1 echo "vpn should now be disconnected ... hit enter to exit" read $exitvpn
net-misc/grdesktop - gnome tool for rdp sessions to wintel servers
nmblookup (samba WINS tool) - give an example of using nmblookup to query a WINS server for a given netbios name
net-misc/kvpnc - a kde vpn management gui
Final Notes go here.