More Linux Server Topics - Network Diagram - About This Site
Chapter 24
Configuring Linux VPNs
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
In This Chapter
Download And Install The FreeS/WAN Package
Possible Changes To IP Tables NAT/Masquerade Rules
How To Ensure FreeS/WAN Starts When Rebooting
© Peter Harrison, www.linuxhomenetworking.com
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
As your SOHO grows, you’ll eventually need to establish some form of VPN link with a supplier, vendor, business partner or customer so that you can directly and freely access all their servers behind their firewall.
A VPN can be really convenient as you’ll be able refer to the remote servers, not by their public NAT-ted IP addresses, but by their real private IP addresses. This avoids problems inherent in connecting to servers behind a “many to one” NAT configuration.
This chapter will outline the configuration of a permanent site to site VPN link or “tunnel” using FreeS/WAN, one of the most popular VPN packages for Linux.
VPN Guidelines
There are some recommended guidelines I’d suggest before attempting a simple SOHO Linux VPN.
· Make sure that the VPN traffic will not pass through a firewall that does NAT. Having a firewall as the VPN “start” or “end” point is OK, just don’t make the tunnel pass through NAT as NAT breaks VPNs.
· Life will be much easier if you make your Linux VPN box also function as a firewall. Configure and test the firewall first and then configure the VPN. The chapter on the iptables firewall should help a lot.
· Take a quick refresher on the main VPN terms.
Scenario
In this example we have two SOHO offices. For simplicity, both sites use IP addressing schemes on their protected networks that do not overlap.
· A VPN needs to be created between the two sites so that they can communicate with each other without the fear of eavesdropping.
· For simplicity, neither site is site wants to invest in a CA certificate service or infrastructure. The RSA key encryption methodology will be used for key exchange. An alternative Cisco compatible “shared secret” (also known as a “pre-shared” or even a “symmetric” key) method will also be discussed at the end of the chapter.
· The network administrators at both sites are aware that permanent site – to – site VPNs require fixed Internet IP addresses and have upgraded from their basic DHCP services originally provided by their ISPs.
Site 1
o uses a private network of 172.168.1.0
o has a Linux VPN / firewall device default gateway with an external Internet IP address of 97.158.253.25
Site 2
o uses a private network of 10.0.0.0
o has a Linux VPN / firewall device default gateway with an external Internet IP address of 6.25.232.1
Download And Install The FreeS/WAN Package
The FreeS/WAN RPM can be downloaded from the website http://www.freeswan.org which has good instructions on how to install the product on RedHat and other versions of Linux. One of the requirements for downloading the RedHat RPM version of FreeS/WAN is to have the ncftp RPM package installed on your system.
Note: Most RedHat Linux software products are available in the RPM format. Downloading and installing RPMs isn’t hard. If you need a refresher, the chapter on RPMs covers how to do this in detail.
Installing the Prerequisite ncftp RPM Package
Use the rpm -qa command to see whether you have the package installed. You’ll need to install it if you get no response from the command below.
ncftp Installed
[root@vpn1 tmp]# rpm -qa | grep ncftp
ncftp-3.1.3-6
[root@vpn1 tmp]#
ncftp not Installed
[root@vpn1 tmp]# rpm -qa | grep ncftp
[root@vpn1 tmp]#
· The latest version of the RPM for RedHat 8.0 is:
ncftp-3.1.3-6.i386.rpm
· Install the package using the following command:
[root@bigboy tmp]# rpm -Uvh ncftp-3.1.3-6.i386.rpm
Installing The FreeS/WAN RPM
Once you have installed ncftp, you can install FreeS/WAN using the recommended commands on the website.
Downloading
Make sure you are in the directory you normally use to download RPMs and then execute the command below. (The command is actually all on one line)
[root@vpn2 tmp]# ncftpget ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/`uname -r | tr -d 'a-wy-z'`/\*
freeswan-allkeys: 132.14 kB 88.72 kB/s
freeswan-allkeys.sig: 460.00 B 2.46 kB/s
freeswan-module-2.00_2.4.18_14-0.i386.rpm: 871.71 kB 138.08 kB/s
freeswan-rpmsign.asc: 1.05 kB 5.78 kB/s
freeswan-sigkey.asc: 1.62 kB 8.75 kB/s
freeswan-userland-2.00_2.4.18_14-0.i386.rpm: 1.18 MB 143.17 kB/s
[root@vpn2 tmp]#
Installing
Use the rpm –ivh command to install the two RPM packages you just downloaded.
[root@vpn2 tmp]# rpm -ivh freeswan*.rpm
warning: freeswan-module-2.00_2.4.18_14-0.i386.rpm: V3 RSA/MD5 signature: NOKEY, key ID 5a7e4731
Preparing... ###################################### [100%]
1:freeswan-module ###################################### [ 50%]
do not forget to install the userland utilities
2:freeswan-userland ################################### [100%]
invoke "service ipsec start" or reboot to begin
[root@vpn2 tmp]#
Starting FreeS/WAN For The First Time
The command below will start FreeS/WAN, but remember you can use the scripts in the /etc/init.d directory to do the same.
[root@vpn2 tmp]# service ipsec start
ipsec_setup: Starting FreeS/WAN IPsec 2.00...
ipsec_setup: insmod: ipsec: no module by that name found
ipsec_setup: insmod failed, but found matching template module 30ae280d.
ipsec_setup: Copying /lib/modules/2.4.18-14/kernel/net/ipsec/30ae280d to /lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o.
ipsec_setup: /sbin/insmod /lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o
ipsec_setup: Using /lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o
ipsec_setup: Symbol version prefix ''
ipsec_setup: WARNING: changing route filtering on wlan0 (changing /proc/sys/net/ipv4/conf/wlan0/rp_filter from 1 to 0)
[root@vpn2 tmp]#
Get The Status Of The FreeS/WAN Installation
The ipsec verify command should give an [OK] status for most of its checks like the one below:
[root@vpn2 tmp]# ipsec verify
Checking your system to see if IPsec got installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking that pluto is running [OK]
DNS checks.
Looking for forward key for vpn2 [NO KEY]
Does the machine have at least one non-private address [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADING [OK]
[root@vpn2 tmp]#
FreeS/WAN Configuration Steps
FreeS/WAN is very forgiving when it establishes a tunnel. It will automatically go through all the various combinations of IKE & IPSec settings with the remote VPN box until it finds a match. You don’t have to configure most of these settings explicitly as you often have to do in the case of routers & firewall/VPN appliances.
Preparation work requires you to draw a basic network diagram like the one above. The VPN box on the left will be called “the left hand side” and the one on the right will be called “the right hand side”.
|
Parameter |
Description |
|
Left |
· Internet IP address of the left hand side VPN device |
|
Leftsubnet |
· The network protected by the left hand side VPN device |
|
Leftid |
· Fully Qualified Domain Name in DNS of the left hand side VPN device preceded by an “@” sign. They can be fictitious, as long as the “left” and “right” ones are unique. |
|
Leftrsasigkey |
· The entire “left” RSA sig public key for the left hand side VPN device. This can be obtained by using the “ipsec showhostkey –left” command. |
|
Leftnexthop |
· The next hop router from the left hand side VPN device when trying to reach the right hand side VPN device. You may use an auto-generated variable “%defaultroute” which will be valid in most cases, or the actual IP address of the next hop router in cases where the next hop is not the default router. |
|
Right |
· Internet IP address of the right hand side VPN device |
|
Rightsubnet |
· The network protected by the right hand side VPN device |
|
Rightid |
· Fully Qualified Domain Name in DNS of the right hand side VPN device preceded by an “@” sign. They can be fictitious, as long as the “left” and “right” ones are unique. |
|
Rightrsasigkey |
· The entire “right” RSA sig public key for the right hand side VPN device. This can be obtained by using the “ipsec showhostkey –right” command. |
|
Rightnexthop |
· The next hop router from the right hand side VPN device when trying to reach the right hand side VPN device. You may use an auto-generated variable “%defaultroute” which will be valid in most cases, or the actual IP address of the next hop router in cases where the next hop is not the default router. |
Once you have all this information you’ll have to enter it in the /etc/ipsec.conf configuration file. The steps to do this will follow.
Get The RSA Keys
In order to configure the /etc/ipsec.conf file you’ll need to get the “left” RSA public key for the “left” VPN device and the “right” key for the “right” VPN device. You’ll need to take note of these and insert them in the /etc/ipsec.conf file.
The FreeS/WAN installation automatically generates the keys, but if you want to change them you can do so by issuing the following command:
[root@vpn2 tmp]# ipsec rsasigkey --verbose 2048 > keys.tmp
getting 128 random bytes from /dev/random...
looking for a prime starting there (can take a while)...
found it after 129 tries.
getting 128 random bytes from /dev/random...
looking for a prime starting there (can take a while)...
found it after 662 tries.
computing modulus...
computing lcm(p-1, q-1)...
computing d...
computing exp1, exp1, coeff...
output...
[root@vpn2 tmp]#
You can then edit the /etc/ipsec.secrets file and replace the contents between the “RSA: {“ and the final “}” with the contents of the keys.tmp file generated from the ipsec command above.
Note: If you cut and paste these keys from the screen into Microsoft “notepad” you’ll find that it may automatically insert carriage return and line feed characters at the end of each line where the text would normally wrap around on the screen. This will corrupt the keys. My experience has been much better cutting and pasting into Microsoft Word or Linux “vi” which behave better. To be safe, just make sure that the all the characters are there especially those at the far left and far right of the “cut” screen and “paste” screen.
Get The Left Key
[root@vpn1 tmp]# ipsec showhostkey --left
# RSA 2192 bits vpn1 Mon Jun 16 21:15:31 2003
leftrsasigkey=0sAQNrV9AYdaW94FXvIxu5p54+MRaW0wy0+HHQrdGofklZYQ4TCBlL+Ym00Ahfc8mqXlerZY12Os41G8SIV+zzIO04WZ4wmOvEr8DZaldTbfCuvUvMhrTtCpZdm53yF5rCaUbg+Vmx71jcIVZqwd2AAocrthuC1riwI8yK9HrSVHzpNQxfRX+F9B//gwWEu1UVcEPkAuY2+Q2tBjg/wmFLEhOrdey7X3NRKyEa6LqgM2Igjhx6vflQg1ImFFyUAL37ie4YSpDnUVzy3tzBVgyPuFHOGyqZtuD/+YkNIhrHfgyVmGu8/kuhzB7nWtOYqDFO8OHDGePOyOVPQi73KfRoDbdb3ND0EtfnRhRPblKJ239OlIq1
[root@vpn1 tmp]#
Get The Right Key
[root@vpn2 tmp]# ipsec showhostkey --right
# RSA 2192 bits vpn2 Mon Jun 16 21:06:20 2003
rightrsasigkey=0sAQNNdxFPWCga+E/AnDgIM+uIDq4UXcZzpomwMFUpyQ9+rhUHT9w8nr3rjUR/qTZOKR2Vqd4XoBd1HkPDBQ8oNjtA3Oz+UQOU3KTMHN5ydFwe6MpTJV/hL6LvhB0OXQad/NhjMIx8vVotlIyZJQVZlHwUevO9/C7W6+8YCfJHJitPOF2aXDT2EKdch/Dn/4p4aiuzy/g8iwjJ+DDBxBYya9aC4GvPqSJhIiX1BwxMOOV+y5FVGs5j9wvOVpF4PJC5tayFuSagDFuuuNELQlQSm9gRRr/ji47xDXsmrzXOnhM8g8SPRnj7pL3abgu7Sg7eFREV1MJSVBhp0DJ0EbVMVV+Xvwlm9++9zbY3mlc+cSXMPAJZ
[root@vpn2 tmp]#
Edit The /etc/ipsec.conf Configuration File
Here we have created a sub-section called “net-to-net” in which we have inserted all the needed parameters. You need to add a new sub-section for each new VPN tunnel.
conn net-to-net
left=97.158.253.25 # Public Internet IP address of the
# LEFT VPN device
leftsubnet=172.16.1.0/24 # Subnet protected by the LEFT VPN device
leftid=@vpn1.site1.com # FQDN of Public Internet IP address of the
# LEFT VPN device with an "@"
leftrsasigkey=0sAQNrV9AYdaW94FXvIxu5p54+MRaW0wy0+HHQrdGofklZYQ4TCBlL+Ym00Ah
fc8mqXlerZY12Os41G8SIV+zzIO04WZ4wmOvEr8DZaldTbfCuvUvMhrTtCpZdm53yF5rCaUbg+Vmx71
fgyVmGu8/kuhzB7nWtOYqDFO8OHDGePOyOVPQi73KfRoDbdb3ND0EtfnRhRPblKJ239OlIq1
leftnexthop=%defaultroute # correct in many situations
right=6.25.232.1 # Public Internet IP address of
# the RIGHT VPN device
rightsubnet=10.0.0.0/24 # Subnet protected by the RIGHT VPN device
rightid=@vpn2.site1.com # FQDN of Public Internet IP address of the
# RIGHT VPN device with an "@"
rightrsasigkey=0sAQNNdxFPWCga+E/AnDgIM+uIDq4UXcZzpomwMFUpyQ9+rhUHT9w8nr3rjU
R/qTZOKR2Vqd4XoBd1HkPDBQ8oNjtA3Oz+UQOU3KTMHN5ydFwe6MpTJV/hL6LvhB0OXQad/NhjMIx8v
OnhM8g8SPRnj7pL3abgu7Sg7eFREV1MJSVBhp0DJ0EbVMVV+Xvwlm9++9zbY3mlc+cSXMPAJZ
rightnexthop=97.158.253.25 # correct in many situations
auto=start # authorizes and starts this connection
# on booting
Some Important Notes About The /etc/ipsec.conf File
· Note: It is important to maintain the indentation before each parameter as shown below.
Right
conn net-to-net
left=x.x.x.x
leftsubnet=y.y.y.y/24
Wrong
conn net-to-net
left=x.x.x.x
leftsubnet=y.y.y.y/24
· Note: The “net-to-net” sub sections must be the same in the /etc/ipsec.conf for both the left and right hand side VPN devices.
Restart FreeS/WAN
This will need to be done on both VPN devices in order for the new /etc/ipsec.conf settings to take effect.
[root@vpn2 tmp]# /etc/init.d/ipsec restart
ipsec_setup: Stopping FreeS/WAN IPsec...
ipsec_setup: Starting FreeS/WAN IPsec 2.00...
ipsec_setup: Using /lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o
[root@vpn2 tmp]#
Initialize The New Tunnel
You can use the ipsec command to start the tunnel “net-to-net” we created in the /etc/ipsec.conf file. You’ll have to issue the command simultaneously on the VPN boxes at both ends of the tunnel or else you may get a timeout error as seen below.
[root@vpn2 tmp]# ipsec auto --up net-to-net
104 "net-to-net" #1: STATE_MAIN_I1: initiate
106 "net-to-net" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "net-to-net" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "net-to-net" #1: discarding duplicate packet; already STATE_MAIN_I3
010 "net-to-net" #1: STATE_MAIN_I3: retransmission; will wait 20s for response
010 "net-to-net" #1: STATE_MAIN_I3: retransmission; will wait 40s for response
031 "net-to-net" #1: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
000 "net-to-net" #1: starting keying attempt 2 of an unlimited number, but releasing whack
[root@vpn2 tmp]#
Retrying the command should get it to work. The “IPsec SA established” message signifies success.
[root@vpn2 tmp]# ipsec auto --up net-to-net
112 "net-to-net" #4: STATE_QUICK_I1: initiate
004 "net-to-net" #4: STATE_QUICK_I2: sent QI2, IPsec SA established
[root@vpn2 tmp]#
Testing Your FreeS/WAN VPN
Check The Routes
You’ll need to check the routes once the VPN tunnel is up. As you can see there is a route to the 172.16.1.0 network via the new “virtual” ipsec0 interface pointing to the VPN device at the other end of the tunnel.
[root@vpn2 tmp]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.0.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
6.25.232.0 0.0.0.0 255.255.255.248 U 40 0 0 wlan0
6.25.232.0 0.0.0.0 255.255.255.248 U 40 0 0 ipsec0
172.16.1.0 97.158.253.25 255.255.255.0 UG 40 0 0 ipsec0
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 6.25.232.6 128.0.0.0 UG 40 0 0 ipsec0
128.0.0.0 6.25.232.6 128.0.0.0 UG 40 0 0 ipsec0
0.0.0.0 6.25.232.6 0.0.0.0 UG 40 0 0 wlan0 [root@vpn2 tmp]#
The “ipsec look” Command
You can also issue the ipsec look command to see whether the tunnel is up and running. You’ll have to double check your keys in /etc/ipsec.secrets and all the values in your /etc/ipsec.conf file if any of these three sections doesn’t appear.
o A section describing the existence of a phase 1 IKE connection that looks like this:
0.0.0.0/0 -> 0.0.0.0/0 => %trap (0)
10.0.0.0/24 -> 172.16.1.0/24 => tun0x1004@97.158.253.25 esp0x1d096702@97.158.253.25 (4)
6.25.232.1/32 -> 0.0.0.0/0 => %trap (4)
Here we can see some form of connectivity between the two networks at either end of the tunnel namely 10.0.0.0/24 and 172.16.1.0/24.
o A section that describes the state of the phase 2 IPSEC tunnel. There will be many “esp” references involving the IP addresses of the VPN devices at either end of the tunnel.
esp0x1d096701@97.158.253.25 ESP_3DES_HMAC_MD5: dir=out src=6.25.232.1 iv_bits=64bits iv=0x7ba1ee06ec8458fe ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(45,0,0) refcount=4 ref=15
o A section whose output is very similar to the netstat –nr section above.
Other causes for failure could include having:
o A firewall blocking traffic
o A firewall NAT-ing traffic. This is bad, please see the Chapter introduction.
o bad cables
Test The VPN Connectivity
You can test the VPN connectivity by sending a simple “ping” from one private network to the other. In this case we’re sending from the Windows server 10.0.0.105 protected by “vpn2” to server 172.16.1.1 which is protected by “vpn1”.
C:\>ping 172.16.1.1
Pinging 172.16.1.1 with 32 bytes of data:
Reply from 172.16.1.1: bytes=32 time=20ms TTL=253
Reply from 172.16.1.1: bytes=32 time<10ms TTL=253
Reply from 172.16.1.1: bytes=32 time=10ms TTL=253
Reply from 172.16.1.1: bytes=32 time<10ms TTL=253
Ping statistics for 172.16.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 20ms, Average = 7ms
C:\>
Protected Interface TCPDUMP Output From “vpn2”
Here we see unencrypted traffic successfully passing back and forth between the two servers.
23:46:46.536831 10.0.0.105 > 172.16.1.1: icmp: echo request
23:46:46.544844 172.16.1.1 > 10.0.0.105: icmp: echo reply
23:46:47.536292 10.0.0.105 > 172.16.1.1: icmp: echo request
23:46:47.543361 172.16.1.1 > 10.0.0.105: icmp: echo reply
Unprotected Interface TCPDUMP Output From “vpn2”
Here we see encrypted ESP traffic which is encapsulating the “pings” passing back and forth between the two VPN boxes. The true source and destination IP addresses (10.0.0.105 and 172.16.1.1) are hidden.
00:00:31.665730 vpn2.site2.com > vpn1.site1.com: ESP(spi=0xcbf056ff,seq=0x9)
00:00:31.668408 vpn2.site2.com > vpn1.site1.com: ESP(spi=0xcbf056ff,seq=0x9)
00:00:31.672554 vpn1.site1.com > vpn2.site2.com: ESP(spi=0x2bc459c8,seq=0x9)
00:00:31.673793 vpn1.site1.com > vpn2.site2.com: ESP(spi=0x2bc459c8,seq=0x9)
Possible Changes To IP Tables NAT/Masquerade Rules
If you are running iptables with masquerading/NAT the VPN devices then you will have to exclude packets traversing the tunnel from the NAT operation. This example assumes that interface eth0 is the Internet facing interface on your Linux VPN/firewall.
Left Hand Side VPN Device
Old
iptables -t nat -A POSTROUTING -o eth0 -s 172.168.1.0/24 -j MASQUERADE
New
iptables -t nat -A POSTROUTING -o eth0 -s 172.168.1.0/24 -d \! 10.0.0.0/24 -j MASQUERADE
Right Hand Side VPN Device
Old
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
New
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 176.16.1.0/24 -j MASQUERADE
How To Ensure FreeS/WAN Starts When Rebooting
The “sample” subsection in /etc/ipsec.conf will have a line:
auto=add
This will only authorize ipsec, but won’t establish the connection at startup. You’ll need to change this in the “real” section to:
auto=start
Once this is done, ipsec will start automatically on rebooting.
Using Pre-Shared Keys (PSK)
Create The PSK
o You can create a random pre-shared key by a key using the ipsec command below:
[root@vpn2 tmp]# ipsec ranbits --continuous 128
0x33893a081b34d32a362a46c404ca32d8
[root@vpn2 tmp]#
o You can also create them out of your head. It is best to make them long (over 20 bytes). We’ll use this one from now on.
nonebutourselvescanfreeourminds
Update /etc/ipsec.secrets
You then have to add text in the following format at the beginning of the /etc/ipsec.secrets file
vpn1-ip-address vpn2-ip-address : PSK “key in quotations”
So in our example it would be:
97.158.253.25 6.25.232.6 : PSK “nonebutourselvescanfreeourminds”
Update /etc/ipsec.conf
The PSK configuration is very similar to the RSA configuration with exception that the leftid, rightid, leftrsasigkey and rightrsasigkey fields are omitted from the relevant “conn” subsection. You also need to add the authtype=secret command to the configuration.
conn net-to-net
authby=secret # Key exchange method
left=97.158.253.25 # Public Internet IP address of the
# LEFT VPN device
leftsubnet=172.16.1.0/24 # Subnet protected by the LEFT VPN device
leftnexthop=%defaultroute # correct in many situations
right=6.25.232.1 # Public Internet IP address of
# the RIGHT VPN device
rightsubnet=10.0.0.0/24 # Subnet protected by the RIGHT VPN device
rightnexthop=97.158.253.25 # correct in many situations
auto=start # authorizes and starts this connection
# on booting
Remember to have the same configuration on the Linux VPN boxes on either side of the tunnel.
Restart FreeS/WAN
You’ll then have to restart FreeS/WAN to activate the new settings.