OpenBSD as a VPN Solution
Alex Withers One of the most pertinent topics in the networking industry today is Virtual Private Networks, or VPNs. In short, VPNs arose out of a need for a cheaper method to connect networks and hosts while still maintaining security and privacy. Many businesses found that in order to connect their branches they had to invest in expensive equipment and leased lines. The same went for providing connections to remote clients; however, in this case the cost went into dedicated modem lines. While methods like these provided for a relatively secure solution, they also tended to be expensive on the implementation and maintenance side. The Internet is an obvious solution to the cost issue by providing one giant medium for connection at a reasonable price (at least when compared with the other solutions). Even though the Internet can be used to get around the cost issue, we still have to deal with security. It is here that VPNs play a part by protecting the data transmitted on the Internet. VPNs essentially form an artificial network on an already existing public network. The technology can authenticate, encrypt data, and provide a secure tunnel between two or more points. As a result, VPNs are being used more often for a cost-effective and secure method to communicate. Many VPN solutions are emerging on the market today, and many of these are offered by big name companies. The technology is often proprietary and very expensive, incurring costs on the software and hardware level. However, since VPNs are more of a concept than an actual technology, we are allowed much working room to implement it. Software such as SSH can be used to create VPNs and there are free Open Source solutions for the free UNIX variants. While these solutions may work fine, they can also be somewhat complex in the implementation process. Another solution involves the OpenBSD operating system. In the case of VPNs, you can take advantage of some of the features OpenBSD has to offer natively. The OpenBSD solution uses a relatively new technology called IPSec. IPSec was designed to secure the existing IP technology. It is independent of any application since it works at a lower level. This is rather convenient, because all data sent is encrypted without having to configure any applications. Implementing the VPN Even within OpenBSD, there are several methods available to deploy IPSec. In this article, I will use the isakmpd daemon. This daemon allows for a secure method to exchange keys between two hosts; however, the configuration can be more sophisticated than “manual keying”. All of the following examples were developed using OpenBSD 2.6, and they may need to be modified for earlier or later versions of OpenBSD. Enabling IPSec in OpenBSD Two variables must be set in order to enable IPSec. They are not set by default, but the following two commands will do the trick:
sysctl -w net.inet.esp.enable=1 sysctl -w net.inet.ah.enable=1The sysctl command is used to change the state of the kernel, and in this case we are enabling AH and ESP. (See the article by Michael Lucas in this issue for more information about sysctl.)You may be wondering what AH and ESP are and what they have to do with IPSec. AH authenticates, but does not encrypt, the data. ESP will authenticate and encrypt the data sent through the network. Both of these are protocols of IPSec and, in the case of isakmpd, should both be enabled. If you wish to have this done each time the system boots, then you need to edit the /etc/sysctl.conf file. To do so, simply add the following two lines:
net.inet.esp.enable=1 net.inet.ah.enable=1To disable it during boot time, simply change the 1’s to 0’s or comment it out with the # symbol. The VPN man page strongly recommends that you have inbound packet verification enabled. To do this, issue the following command:
sysctl -w net.inet.ip.ipsec-acl=1If the host will be a gateway, then you must make sure IP forwarding is enabled. This is yet another sysctl command:
sysctl -w net.inet.ip.forward=1Add these to the sysctl.conf like the first two tags in order for this to take place during boot time. Once everything has been enabled, IPSec is ready to be configured. The isakmpd Daemon OpenBSD 2.6 should come with the isakmpd binaries without having to take any further steps after installation. When dealing with isakmpd, there are two main files that will occupy our attention:
/etc/isakmpd/isakmpd.conf /etc/isakmpd/isakmpd.policy.The first of these is the configuration file, which determines the behavior for isakmpd. The latter file is the policy file, which tells how to authenticate connections. These two files are very important because they are the keys to creating the VPN. Configuring isakmpd Step One: isakmpd.policy Our scenario for discussion involves three networks: 10.0.1.0, 10.0.2.0, and 10.0.3.0. Each of these networks has a main router: 10.0.1.1, 10.0.2.1, and 10.0.3.1. These networks will communicate using the “outside” network: 192.168.1.0. In the real world, this “outside” network may very well be the Internet. In this example, each router will be connected to the “outside” network with the following IP addresses: 192.168.1.1, 192.168.1.2, and 192.168.1.3. Each of these routers is running OpenBSD 2.6, and they will be the boxes configured for this example of a simple VPN.
Unfortunately, the default installation of OpenBSD does not come with the isakmpd.policy or isakmpd.conf files. However, there are example files available if you have the official OpenBSD CD-ROM or can get them through CVS. Under the /src/sbin/isakmpd/samples directory, there are two files that can be useful: policy and VPN-east.conf. Simply copy the file policy to /etc/isakmpd/ \ First, edit the isakmpd.policy file to specify who can connect using IPSec. If we wanted to allow anyone to connect, then isakmpd.policy would look like this:
KeyNote-Version: 2 Comment: A policy which accepts anyone.> Authorizer: "POLICY"This would probably be useful only for testing purposes, as it is not very secure. For something more secure, we could use the following:
KeyNote-Version: 2
Comment: A policy which accepts anyone \
that uses "yoursecret" as a passphrase.
Authorizer: "POLICY"
Licensees: "passphrase:yoursecret"
Conditions: app_domain == "IPsec policy" &&
esp_present == "yes" &&
esp_enc_alg != "null" -> "true";
Note that a lot more can be done with this file, and you should refer to the isakmpd.policy man pages for more information. We could use digital certificates or other such things for authentication. I will keep this example simple and use a passphrase.Step Two: isakmpd.conf The next step is to modify the isakmpd.conf file. Since we have three networks between which we would like to establish a VPN, we need to tell each router about the other two routers. But before we do this, each isakmpd.conf needs to have the following:
[General] Retransmits= 3 Exchange-max-time= 60 Listen-on= 192.168.1.xThe first variable, Retransmits, tells isakmpd how many times a message should be retransmitted before it gives up. The second variable, Exchange-max-time, gives the number of seconds available for an exchange to set up. The third variable, Listen-on, gives the IP address of the external interface and, in this example, the x should be replaced with 1,2, and 3 for each machine, respectively. There are many more parameters available under the General section (see the isakmpd.conf(5) man page). These values should be tweaked, since every network and situation is different. When establishing an IPSec connection between two nodes, there are two phases. The first phase establishes the secure connection, and the second phase does the rest of the work by establishing the tunnel in a secure connection. Therefore, the next section in the configuration file specifies the daemon from which it can accept connections:
[Phase 1]: 192.168.1.2= host2 192.168.1.3= host3The above would have been what host1 (192.168.1.1) needs in its configuration file. Thus, in this scenario, every host would need the other two hosts listed. Now, we add a section for the second phase:
[Phase 2]: Connections= host1-host2 Connections= host1-host3This section has also been taken from what would have been the configuration for host1, and describes the possible connections. Note that the right-hand side values are quite meaningless, since they are nothing but strings that signify the name of the next sections. It is after the phase 2 section that these sections are defined. Continuing with host1, we add the next section to the configuration file:
[host2] Phase= 1 Transport= udp Address= 192.168.1.2 Configuration= MainMode Authentication= yoursecret [host3] Phase= 1 Transport= udp Address= 192.168.1.3 Configuration= MainMode Authentication= yoursecretSince we are dealing with host1, we listed the two other nodes. The Transport flag tells isakmpd which protocol to use. The Address flag gives the IP of the remote node. The Configuration flag points to another section, and the Authentication flag is the passphrase matched with the policy found in isakmpd.policy. Note that this setup is similar to the example configuration file provided by OpenBSD. Also note that in regard to the Transport flag, some firewalls won’t allow UDP packets, so some change would be necessary. Next, we define the sections referred to in the phase 2 section:
[host1-host2] Phase= 2 ISAKMP-peer= host2 Configuration= QuickMode Local-ID= Net1 Remote-ID= Net2 [host1-host3] Phase= 2 ISAKMP-peer= host3 Configuration= QuickMode Local-ID= Net1 Remote-ID= Net3Remember that we are still dealing with host1’s configuration. The ISAKMP-peer flag (host2) refers to the remote node. The Configuration flag refers to a section further below in the configuration file. The Local-ID and Remote-ID flag refers to the sections that describe the networks we are dealing with. We would define those sections in host1’s configuration file as follows:
[Net1] ID-type= IPV4_ADDR_SUBNET Network= 10.0.1.0 Netmask= 255.255.255.0 [Net2] ID-type= IPV4_ADDR_SUBNET Network= 10.0.2.0 Netmask= 255.255.255.0 [Net3] ID-type= IPV4_ADDR_SUBNET Network= 10.0.3.0 Netmask= 255.255.255.0The ID-type describes the node and might be IPV4_ADDR instead. The Network and Netmask flag give the appropriate numbers to describe the private network. Now we need to define the MainMode and QuickMode. These describe the encryption methods for the first and second phases, respectively.
[MainMode] DOI= IPSEC EXCHANGE_TYPE= ID_PROT Transforms= BLF-SHA-M1024 [QuickMode] DOI= IPSEC EXCHANGE_TYPE= QUICK_MODE SUITES= QM-ESP-3DES-SHA-PFS-SUITEThe Transform tag in MainMode tells isakmpd to use the blowfish algorithm for encryption and the SHA hashing algorithm. There are many to choose from, and the example configuration in the isakmpd.conf man page lists some. The SUITES tag in the QuickMode section points to predefined sections, but it basically tells isakmpd to use the ESP protocol, Triple DES for encryption, and the SHA hashing algorithm. These tags, Transform and SUITES, point to predefined sections, which can be found in the OpenBSD’s sample configuration file or the isakmpd.conf man page, but they aren’t necessary for the configuration file. Preparing for and Running isakmpd If the machine is a gateway to a network, then it’s a good idea to make it a firewall. All incoming packets, except those from the VPN, should be blocked. To do this, open a plain text file for the firewall rules:
block in log on <network-interface> \ from any to any block out log on <network-interface> \ from any to any block in log on enc0 from any to any block in log on enc1 from any to any pass in proto esp from 192.168.2.1/32 \ to 192.168.1.1/32 pass in proto esp from 192.168.3.1/32 \ to 192.168.1.1/32 pass out proto esp from 192.168.1.1/32 \ to 192.168.2.1/32 pass out proto esp from 192.168.1.1/32 \ to 192.168.3.1/32 pass in on enc0 from 10.0.2.0/24 to 10.0.1.0/24 pass in on enc1 from 10.0.3.0/24 to 10.0.1.0/24This set of firewall rules would be used on host1. The rules are quite easy to read, and it’s not hard to understand what is going on here. Note that <network-interface> should be changed to the external interface of the machine (the interface connected to the external network). Also, enc0 and enc1 are the IPSec interfaces from which host1 receives the packets. The above rules will block any incoming traffic, but we need to make sure a connection can be established. Since isakmpd works on port 500 using the UDP protocol, incoming packets need to be allowed in:
pass in proto udp from 192.168.2.1/32 \ to 192.168.1.1/32 port = 500 pass in proto udp from 192.168.3.1/32 \ to 192.168.1.1/32 port = 500Because I am still using host1 as an example, I am allowing UDP traffic on port 500 from 192.168.2.1 and 192.168.3.1. Now that you have compiled these rules (and any others you might need) in a text file, you must pipe it to OpenBSD’s firewall tool, ipf:
ipf -f textfileIf you want this done every time during boot, then add ipfilter=YES to the /etc/rc.conf file. Now, ipf will read the /etc/ipf.rules during boot time. The next step is to run the daemon. To run the daemon in the foreground, simply use the -d flag as follows:
isakmpd -dUsing the -DA=99 option will set all debugging classes to level 99. This will provide quite a bit of information. If isakmpd is not started during boot time automatically, then edit /etc/rc.local. You can now test your setup by sending traffic between the two nodes and using tcpdump to see whether the traffic contains ESP or AH packets. Conclusion The examples I used here were for a simple VPN, which worked well enough for my employer, but isakmpd is extremely flexible. There are many more options to use in isakmpd for authentication, such as X509 digital certificates. isakmpd is also known to work with many popular VPN clients, which are listed in the OpenBSD FAQ. I strongly suggest going through all the man pages for isakmpd, ipsec, vpn, etc. I also suggest reading the OpenBSD FAQ. These were my primary resources, and they contain many more examples, especially with digital certification. Since OpenBSD tightly integrates cryptography, the solutions for a VPN are myriad and easy to deploy. OpenBSD is also very secure and rock stable, and with support of hardware encryption just around the corner, OpenBSD can be very attractive in many situations. n
About the Author
Alex Withers (awithers@gonzaga.edu) is currently a student at Gonzaga University in Spokane, WA. When not sitting through the riveting lectures, Alex either works to administer networks or enjoys running.
|