Professional Documents
Culture Documents
Linux VPN Howto
Linux VPN Howto
By David.K
VPN Guidelines
Here are some recommended guidelines that I suggest you consider before attempting a simple SOHO
Linux VPN.
The IPSec protocol on which VPNs are based will not tolerate its data packets being network address
translated. If your firewall does NAT, then you'll have to disable it specifically for the packets that will
traverse the VPN.
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 networks at both ends of the VPN tunnel must use different IP address ranges. Many company
networks operate using 192.168.0.x or 192.168.1.x addresses, you may have to reassign IP
addresses to your network if overlaps occur.
Permanent site-to-site VPNs require firewalls at both ends that use static, DHCP IP addresses.
Scenario
Here's the scenario.
The two sites need a VPN so that they can communicate with each other without the fear of
eavesdropping.
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. The sites' IP addressing schemes do not overlap.
Neither site wants to invest in a CA certificate service or infrastructure. The RSA key encryption
methodology will be used for key exchange. (At the end of the chapter, I'll discuss an alternative
Cisco-compatible method called alternately shared secret, pre-shared, or symmetric key.)
Site 1 uses a private network of 172.168.1.0 /24 and has a Linux VPN/firewall device default gateway
with an external Internet IP address of 97.158.253.25.
Site 2 uses a private network of 10.0.0.0 /24 and has a Linux VPN/firewall device default gateway
with an external Internet IP address of 6.25.232.1.
Install it using
The -U qualifier is used for updating an RPM to the latest version, the -h qualifier gives a list of hash #
characters during the installation and the -v qualifier prints verbose status messages while the command
is run.
Configuring OpenSwan
You can configure Openswan to start at boot time using the chkconfig command:
You can start, stop, and restart Openswan after booting using the ipsec initialization script as shown:
Remember to restart the ipsec process every time you make a change to the ipsec.conf file for the
changes to take effect on the running process.
Immediately after installing Openswan, run the ipsec verify command. It should give an [OK] status for
most of its checks:
IP forwarding
Each Linux VPN device needs to have routing or IP forwarding enabled. To enable it, simply add an
ip_forward entry to the /etc/sysctl.conf file by using an editor such as vi or vim.
#
# File: /etc/sysctl.conf
#
#---------------------------------------------------------------
# Enable routing (IP forwarding)
#---------------------------------------------------------------
net/ipv4/ip_forward = 1
Now use the sysctl -p command to activate the settings.
[root@bt]# sysctl -p
...
...
net.ipv4.ip_forward = 1
[root@bt]#
This feature should be disabled by default in your configuration file; simply ignore the errors related to it.
Preparation work requires you to draw a basic network diagram such as Figure 35.1. The VPN box on the
left is called the left-hand side and the one on the right is called the right-hand side. Left and right
parameters must be configured in the /etc/ipsec.conf configuration file. Table 35-1 explains each
parameter.
Table 35-1 Parameters of the /etc/ipsec.conf file
Parameter Description
Leftid Fully qualified domain name in DNS of the left-hand side VPN device, which is preceded by
an "@" sign. If DNS is set up for the IP addresses, remove this entry, because names that
don't resolve correctly cause the VPN initialization to fail.
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.
Rightid Fully qualified domain name in DNS of the right-hand side VPN device, which is preceded by
an @ sign. If DNS isn't set up for the IP addresses, remove this entry, because names that
don't resolve correctly cause the VPN initialization to fail.
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.
First you must gather all this information, then you have to enter it in the /etc/ipsec.conf configuration file.
To configure the /etc/ipsec.conf file, you need to get the left RSA public key for the left VPN device and
the right key for the right VPN device. You need to generate these and insert them in the /etc/ipsec.conf
file of the VPN peer device.
The best approach is to generate files containing these keys and then use the vi editor's read command
(r) to read them into your /etc/ipsec.conf file. Cutting and pasting screen output over an SSH session 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 can corrupt the keys.
The Openswan installation automatically generates the keys. If you want to change them, you can issue
the command:
You can then edit the /etc/ipsec.secrets file and replace the contents between RSA: { and the final } with
the contents of the keys.tmp file generated from the ipsec command above.
On the left VPN server, issue this command to export the left public key to a file named /tmp/left.pub.
Each VPN in the /etc/ipsec.conf file has its own subsection. The example creates a subsection called net-
to-net, which then receives all the needed parameters.
#
# File: /etc/ipsec.conf
#
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.my-site.com # FQDN of Public Internet IP address of the
# LEFT VPN device with an "@"
leftrsasigkey=0sAQNrV9AYdaW94FXvIxu5p54+MRaW0wy0+HHQrdGofklZYQ4TCBlL+Ym00Ahfc
8mqXlerZY12Os41G
8SIV+zzIO04WZ4wmOvEr8DZaldTbfCuvUvMhrTtCpZdm53yF5rCaUbg+Vmx71fgyVmGu8/kuhzB7n
WtOYqDFO8OHDGePOyO
VPQi73KfRoDbdb3ND0EtfnRhRPblKJ239OlIq1
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.another-site.com # FQDN of Public Internet IP address of the
# RIGHT VPN device with an "@"
rightrsasigkey=0sAQNNdxFPWCga+E/AnDgIM+uIDq4UXcZzpomwMFUpyQ9+rhUHT9w8nr3rjUR/
qTZOKR2Vqd4XoBd1s
HkPDBQ8oNjtA3Oz+UQOU3KTMHN5ydFwe6MpTJV/hL6LvhB0OXQad/NhjMIx8vOnhM8g8SPRnj7pL3
abgu7Sg7eFREV1MJSVB
h p0DJ0EbVMVV+Xvwlm9++9zbY3mlc+cSXMPAJZ
rightnexthop=97.158.253.25 # correct in many situations
auto=start # authorizes and starts this connection
# on booting
Be sure to maintain the indentation before each parameter. The correct arrangement is.
conn net-to-net
left=x.x.x.x
leftsubnet=y.y.y.y/24
Do not use
conn net-to-net
left=x.x.x.x
leftsubnet=y.y.y.y/24
The net-to-net subsections must be the same in the /etc/ipsec.conf for both the left- and right-hand side
VPN devices. You can configure VPNs to other remote destinations in this file as long as they don't share
a subsection name with other VPNs. So in this example, there should be only one net-to-net subsection
which uniquely defines the VPN between our two sample sites.
Also, make sure no blank lines separate the net-to-net section's parameters. Lines commented with a #
character are acceptable.
Restarting IPSec to reload the configuration file doesn't necessarily restart the tunnels. If you set the
auto= parameter to add, you can start the tunnel only manually with the ipsec command. If the parameter
is commented out, then the tunnel will never start. A value of start causes the tunnel to start
automatically.
Restart Openswan
On both VPN devices, you need to start Openswan for the new /etc/ipsec.conf settings to take effect.
To initialize the new tunnel, you can use the ipsec command to start the tunnel net-to-net. Be sure to
issue the command simultaneously on the VPN boxes at both ends of the tunnel.
The troubleshooting section at the end of the chapter shows you how to test that everything is working
correctly.
to
to
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 176.16.1.0/24 -j
MASQUERADE
You must change this to auto=start for Openswan to start the VPN automatically when IPSec restarts or
when the system reboots.
1) Create the PSK using one of two methods. You can create a random pre-shared key using the ipsec
command.
Or, you can create them out of your head. Make them long (over 20 bytes), as in.
Nonebutourselvescanfreeourminds
2) Update /etc/ipsec.secrets by adding text in this format at the beginning of the file.
3) 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. Also 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 and to
restart Openswan to activate the new settings.
Troubleshooting Openswan
Troubleshooting is always important when setting up VPNs, because many things can go wrong. Here
are some quick checks you can do to make sure all is working correctly.
The ipsec auto --status command provides a status on Opesnswan running on your VPN device. The
output is divided into three sections:
IKE Section: Defines the various encrypted key exchange algorithms and their parameters. At least
one set of values must match between the left- and right-hand side VPN devices. This is also
frequently referred to as the Phase 1 parameters, because the key exchange process is the first thing
to occur in establishing a VPN.
ESP Section: Defines the various data encryption algorithms and their parameters. At least one set
of values must match between the left- and right-hand side VPN devices. This is also frequently
referred to as the Phase 2 parameters, because the data encryption process is the second and final
thing to occur in establishing a VPN.
VPN Section: This is usually prefaced by the name of the VPN tunnel, in this case net-to-net. If there
are no entries, then the VPN hasn't been established at all. If there are entries, but no
STATE_QUICK_R2 (IPsec SA established) lines then the IPSec parameters are configured, but the
tunnel hasn't been established. This can be normal, tunnels become active once the Phase 1 and
Phase 2 security associations are created, and this usually only occurs after traffic is flowing. The
associations then get torn down after a timeout period. It is always best to pass traffic over the tunnel
to activate them. An ICMP ping check is a good way to test this.
It is important to know the status of your VPN as it can provide valuable troubleshooting clues when there
are problems. This can be especially important when establishing a VPN between your Linux firewall and
a non-Linux device. The IKE and ESP timers, and encryption, hash and key exchange algorithms must
match at both ends to have success. This command allows you to see the value combinations Openswan
is using and help you configure the VPN device on the other end to have compatible settings.
You can test the VPN connectivity by sending a simple ping from one private network to the other. In this
case, the ping goes to the Windows server 10.0.0.105, which protected by vpn2, from server 172.16.1.1,
which is protected by vpn1.
If the tunnel is up but ICMP pings don't work, then you need to check that the servers at both ends of the
tunnel have routes pointing to the VPN firewalls. Also, check for additional network access controls
between the servers and the VPN firewall. There may be additional firewalls in the way or the servers
themselves may be running firewall software:
C:\>ping 10.0.0.105
C:\>
Check The Routes
You'll need to check the routes after the VPN tunnel is up as well. As you can, see there is an additional
route to the 172.16.1.0 network on firewall vpn2. Incorrect routing on the firewalls can cause problems,
check your leftnexthop and rightnexthop values in your /etc/ipsec.conf file.
Using TCPdump
If the tunnel doesn't appear to become established, use the tcpdump command as below. You need to
know whether the IPSec packets are even reaching your VPN firewall. Check routing and your Openswan
configuration if not.
Here the encrypted ESP traffic 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.
As always, check your /var/log/messages file for any messages that may provide clues as to the source of
your problems.
If your left and right public keys were incorrectly applied to your /etc/ipsec.conf file or your regenerated
keys were not updated in your /etc/ipsec.secrets file, then you will get messages stating that the keys are
invalid and that information is being ignored.
Conclusion
VPNs are increasingly becoming an everyday part of life on the Internet. Many people use them to gain
access to many of the systems in their offices, such as e-mail and intranets. This trend is certain to
become more popular as many companies are finding it cheaper for their employees to work from home,
relieving them of the need to lease additional office space.
Site-to-site VPNs will also continue to be deployed as companies, both small and large find it increasingly
necessary to share access to their business systems. One notable area is in the realm of IP telephony,
where VPNs enable all remote offices to use a single IP switchboard at the center of a VPN hub and
spoke network. Intra-office communication is therefore encrypted and the use of a single switchboard
saves costs.