This paper is not a replacement for the original documentation provided by the manufacturers of the products mentioned herein.

The views and opinions expressed in this document represent those of the author unless otherwise stated. Various parties have contributed to this document. The author and his sponsors cannot guarantee the validity and/or deployment implications of the information contained in this document. In short, this information is provided as-is, and nobody but the reader can be held responsible for any damage that may result from the use of information contained in this document.

This document is by no means an endorsement that the scenarios presented are the most efficient and secure way to set up a VPN. The intent is to provide a basic knowledge of how VPNs work. By using the information provided, the reader acknowledges that the author and/or maintainer of this document cannot be held accountable for any misuse and/or ill effects caused by following the procedures herein.

The domain and hostnames used in this document are not fictional. They are property of the author and/or SecureOps Inc. Please do not use the domain names mentioned in this example for your personal or corporate use without the consent of either the author and/or his sponsors.

A Virtual Private Network (VPN) allows two private networks to be connected over a publicly-accessible network. Some people confuse this definition with that of an encrypted tunnel, but it is not necessarily the same thing. A VPN often is composed of an encrypted tunnel, but it is not a requirement to the definition. In fact, there are certain VPN configurations that do not require a tunnel at all. In other words, a VPN is just the extension of a private network over a public infrastructure.

The concept behind a VPN is fairly simple, but to understand how it operates, it is important to understand the fundamental building blocks of a network. A private network is composed of two or more inter-connected computing resources. As the network grows it is broken down into segments by network devices such as routers, bridges, switches and the like. Local Area Networks (LANs) become inter-connected with Wide Area Networks (WANs). At this point, a single organisation can still privately own all the portions of their network. As the Internet and other world-wide networks grow, companies find it costly to implement their own network deployments and opt for the cheaper alternatives such as those provided by Service Providers and/or Internet Service Providers and connect their LANs through a public network or the Internet.

But using a public network brought about interesting challenges to many organisations. How could private resources be made available to branches or users connected via a public network? As we will see later, this made it necessary for the development of encryption, tunnelling and authentication schemes. Thus was born the Virtual Private Network concept.

Suppose that an organisation has a small office with 4 computers in the Production department. These four computers could be fitted with Ethernet cards to enable the sharing of scarce resources such as printers and disk drives. The IT department, being efficient and doing a good job at paying attention to the organisation’s needs for expansion, decides to network these computers using IP protocols because they foresee connecting to the Internet at a later date.

A few months later, with the growth of the organisation, the IT staff installs four more computers for the Accounting department. They decide to differentiate between these two departments by segmenting them. They assign 192.168.10.X to one department and 192.168.20.X to the other. By doing so, they create two subnets on the private network and separate them by a router.

According to the laws of IP, if these two networks decide they wish to speak to each other, a Gateway must be introduced between them in order to route the packets from one subnet to the other. This gateway, most often called a router, is the basis of connecting networks together. At the network level, the Internet is a collection of subnets joined together by these routers.

The organisation expands more and opens up an office across the continent. There is now a need to share resources from one office to the other. Although there may be more than one scheme to consider in connecting these two offices, the IT department decides to adopt the VPN solution. 192.168.10.X and 192.168.20.X are now in different locations. The VPN software (or hardware, depending on the implementation) acts like a chainsaw that cuts the router box in half. By doing so, the routing functionality of the single router is divided into two separate routers at either end of the VPN. This is called a VPN gateway. The two halves are now linked over a public network containing public routable IPs . Both network segments can still talk to each other through a virtual tunnel even if they are separated by a great distances. You now have a VPN.

There are several possible scenarios in which one would use a Virtual Private Network. One example would be a field engineer who needs to establish a link back to his headquarters to use a file server or a central database. In this case, the field engineer would connect to the Internet using a laptop and establish a VPN between his laptop and a gateway on the private network. This would be a HOST to LAN VPN.

Furthermore, imagine that the organisation is very small or wishes to limit its exposure to the public network. As a result, the company wants the field engineer to connect directly from his laptop to a central database that is connected to the Internet. There is no need for a gateway, so a HOST to HOST VPN is established, creating a private network between the central database and the field engineer’s laptop.

The Internet as it stands is a fairly hostile place. In order to keep your information safe, your VPN must be able to ensure the following:

These are all provided by current VPN technologies. Several methods have been developed with the goal to provide the above four steps in some way, shape, or form. Examples would be the Point to Point Tunnelling Protocol (PPTP), the Layer 2 Tunnelling Protocol (L2TP) and IPsec. Each has their strong points and their issues. The current trend is to combine some of these techniques in order to provide tunnelling along with the four points mentioned above. At present, we will focus mainly on the IPsec suite.

IPsec means ‘Internetworking Protocol Security’. IPsec is a method of establishing a connection between two points that complies with the 4 requirements to establishing a VPN. IPsec itself was not specifically designed for use in a VPN configuration, but rather to account for the lack of security in the Internet Protocol suite.

IPsec is a subset of IP and must therefore obey the standards imposed by IPv4. IP is a protocol suite that provides for an IP header that takes care of the propagation of the data on the network and a payload portion that takes care of the transportation of the data. IPsec protects the data by inserting itself into the payload portion of IP. In essence, this means that it includes itself in the transport (commonly referred to as TCP or UDP) portion of a TCP/IP packet, and replaces it with its own combination of transport protocols known as Authentication Header (AH) and Encapsulated Security Payload (ESP). Both of these protocols address the four concerns stated in 2.2 directly.

IPv4 is designed to allow the differentiation of the routing and flow control of the data. It allows for control over the method of delivery and the verification of the proper arrival of that data separately. This implies that a parity check is done at both the network (IP) and the transport (UDP or TCP) levels. There are no mechanisms in place to permit the verification of the data’s authenticity or integrity while in transit, at least, not beyond relying on the source and destination and a few weak parity checks. Furthermore, the information can appear authentic even if modified by an intercepting party. TCP actually allows for a sequence number that provides basic replay protection but it’s easily compromised on some systems. Confidentiality is not covered by the IP suite of protocols, either.

AH and ESP are methods of using the facilities in place to enforce a security scheme that does not depend on the transport layer. These facilities are based on the only information available, which is that of each packet’s IP header. That packet starts its life in the standard TCP/IP stack of your operating environment looking like this:

The packet is then passed on to the IPsec stack for further processing. At this point, the way you have configured your IPsec connection, ESP and AH and whether you are using TRANSPORT or TUNNEL will affect what your packet looks like. An example would be:

AH authenticates the packet being sent by presenting a strong cryptographic hash (much like a digital signature) of the packet’s IP header. If the IP header was changed in transit, then the AH facility will be able to account for it. ESP provides for replay protection, privacy, and integrity. It takes the transport layer of the TCP/IP packet and encrypts it using a cryptographic algorithm such as DES or 3DES and then signs it using a cryptographic hash such as SHA1 or MD5.

This creates certain problems. For example, how does the receiving party know that the packet is being sent from a trusted source? How does the receiving party know how to decrypt each packet? IPsec provides for this by establishing a Security Association (SA).

An SA is a one-way connection between two gateways that will provide the parameters in which to mould the packet being sent to the receiving party. For example, a Security Association is established between a sending gateway and receiving gateway. When traffic is sent to the receiving party, the SA provides the IPsec stack with the information with which to mould the outgoing packet. Is it using ESP? What key should be used to encrypt the packet? Should it be sent using tunnelling or transport mode? Is it using AH? What hash should be used for the checksum?

Each SA can handle only one of the IPsec protocols. If both AH and ESP protection is applied to a packet, then two SAs are required to provide protection to that packet. In order to secure packets flowing back and forth between two gateways you will normally need two SAs: one each for outgoing and incoming packets on each gateway.

A security association is uniquely identified by a triplet consisting of a Security Parameter Index (SPI), an IP Destination Address, usually that of the receiving gateway, and a security protocol (AH or ESP) identifier.

ISAKMP (or IKE) is the key exchange mechanism for a VPN. It meets security concerns using the methods mentioned in RFC 2407, RFC 2408 and RFC 2409. ISAKMP manages the exchange of cryptographic keys that you would normally have to manually manage with ipsecadm(8). It employs a two-phase process for establishing the IPsec connection between two gateways.

The two ISAKMP peers establish a secure, authenticated channel through which to communicate. This establishes an SA between both hosts for the purpose of identification.

In the case of OpenBSD, the tag=value pairs define the requirements to be met for the set-up of this SA. This typically implies that both the sender and receiver present a proof of identity to each other, such as an X509 certificate signed by a Certificate Authority or a pre-shared secret. Other information can also be cross-referenced to make sure everybody is who they say they are. For instance, the ID can include the sender’s IP address, fully qualified domain name, or username.

Phase 1 also establishes the manner in which the information will be transmitted. Main Mode and Aggressive Mode are the methods used to establish the channel. Main Mode sends authentication information in a specific sequence, providing identity protection because it requires that information be sent back and forth between the sender and the receiver before the sender’s full identity be established. Aggressive Mode does not provide identity protection because all of the authentication information is sent at the same time. Aggressive Mode should only be used in such cases where network bandwidth is an issue or in situations where the sender needs to identify itself so that the receiver can pick a Phase 1 configuration that matches this particular identity.

ISAKMP negotiates SAs for IPsec and determines what encryption algorithm to use, how long the keys should be kept and so on. By doing so, it establishes the link between the gateways by providing the appropriate IPsec SAs. Quick Mode is used in Phase 2 because the SAs already have all the information to communicate with each other.

This reasoning may seem confusing at first, but it makes sense if you think about it (And read the RFCs in the proper order!). Phase 1 is where your two gateways establish a connection and exchange authentication information. (Either a X509 certificate or a pre-shared secret). This allows each end to make sure the other end is who they say they are. Phase 2 is an exchange of keys to determine how the data between the two will be encrypted. In other words, Phase 1 is analogous to your phone ringing, you answering and the initial greeting : 'Hi John, it's Jane.' Phase 2 is the determination of the language you are going to use to continue your conversation.

This scenario assumes that the average user will want to install their VPN gateway on the machine that directly connects their network to the Internet. Note that installing the VPN software directly on the gateway exposed to the Internet may not necessarily be a great idea, but in this case it offers the simplest scenario. This scenario also solves some more technical implementations that may require LANs to use NAT or Proxies.

To make life easy, IP addresses will not be assigned in this scenario. Please refer to the following diagram for host and network names used in this example. This scenario is based upon the isakmpd.conf MAN page.

The goal here is to make users from Badplants.com Private Network able to communicate with Carefull.com's private network to make use of their printer server. They don't want anybody from the outside world (that’s the Internet, of course) to be able to see what they are trying to print, or even be able to acknowledge the fact that they are printing at all.

This should already be done if the OpenBSD box is already being used as a Gateway. All network nodes need to have their default gateway set to Slippery - Private IP and Ragweed - Private IP respectively.

The sample files are located in the CVS tree at

src/bin/isakmpd/samples/VPN-east.conf => isakmpd.conf

src/bin/isakmpd/samples/policy => isakmpd.policy

Edit the /etc/sysctl.conf file:

uncomment or add the following lines:

net.inet.ip.forwarding=1

net.inet.esp.enable=1

net.inet.ip.ipsec-acl=1

This file tells ISAKMP who can access IPsec. In the current scenario, the isakmpd.policy file states that anybody who sends data using ESP and has authenticated with the passphrase mekmitasdigoat (or whatever passphrase that is determined), is allowed to use the IPsec stack. This can be modified to let ISAKMP know that only data signed with certain digital certificates, certificates that have been signed by a certain CA, or are using a certain encryption transform are allowed to use IPsec. An extreme case would be to allow anybody to access IPsec. For the minimum security settings all that is required is:

KeyNote-Version: 2
Authoriser: "POLICY"

The sample file supplies what is considered to be the minimum security constraints. For more security, or certificate use, the file must be further configured.

Unfortunately, there is a problem with the original sample policy file that comes with the distribution. It contains 2 lines of code that are not supported by keynote(5). This is easily fixed by deleting the two lines in question (these are added for CVS):

KeyNote-Version: 2
Comment: This policy accepts ESP SAs from a remote that uses the right password
OpenBSD: policy,v 1.3 1999/11/18 21:45:52 angelos Exp $
$EOM: policy,v 1.3 1999/08/26 11:51:37 niklas Exp $
Authoriser: "POLICY"
Licensees: "passphrase:mekmitasdigoat"
Conditions: app_domain == "IPSec policy" &&
esp_present == "yes" -> "true";

Further customising of this policy file is required if you want to assure a secure atmosphere in which to use IPsec and keep crackers at bay. Further discussion is available in the isakmpd.policy(5) man page and on http://www.openbsd.org/faq/faq13.html.

As mentioned before, this is the basic example taken straight out of the isakmpd.conf MAN page. Implementing this will result in a basic VPN using ESP only. The isakmpd.conf file is in the traditional .ini format: Anything in block quotes ([ ]) is a section name. Each section has tag=value pairs.

The isakmpd.conf file follows a certain tree format. Therefore, certain tag=value pairs contain, as a value, the name of a section that is declared elsewhere in the file. The discussion below addresses the requirements to set up a host-to-host VPN between slippery.carefull.com and ragweed.badplants.com and why these values are established.

[General]

Retransmits= 5

Exchange-max-time= 120

Listen-on= Slippery_Internet_IP

[General]

Retransmits= 5

Exchange-max-time= 120

Listen-on= Ragweed_Internet_IP

This section sets up the variables that will affect the main behaviour of ISAKMP as a daemon. It is okay to use the defaults here as they are usually acceptable in most cases.

The Retransmits value describes the number of attempts that should be made when transmitting a Phase 1 proposal before determining that it will not be chosen by the receiver. Remember that using UDP for Phase 1 does not provide any information as to whether or not a packet has reached its destination.

The Exchange-max-time sets the timeout limit in seconds. This means that if there is a pause of more than two minutes during the establishment of a Phase 1 connection then it will time out and re-initiate the connection.

The Listen-on value is the IP to which ISAKMPD should bind. Only the IP address of the gateway that is connected to the public network or Internet is necessary here because the private IP space has no need to connect to ISAKMPD. If multiple external interfaces are on the gateway then the interfaces which should be listening can be listed by entering them using a comma separated list.

[Phase 1]

Ragweed_Internet_IP= Ragweed

[Phase 1]

Slippery_Internet_IP= Slippery

This section describes the Source IP addresses to accept in order to negotiate the phase 1 connection. Its value points to a section below. Multiple peers can be listed as IP_Address= <ISAKMP-PEER>.A Default tag can also be included for the connection from which no means of predicting the IP address is available.

[Phase 2]

Connections= Slippery-Ragweed

[Phase 2]

Connections= Ragweed-Slippery

These describe different IPsec Security Associations to be established. Note that by using the Connections tag, each gateway will try to initiate a connection to the other the instant that the ISAKMP daemon is started. In certain situations this may not be appropriate; If a gateway should only listen for an incoming connection and not initiate it use the Passive-connections tag instead.

The Connections tag refers to a section name mentioned below that describes the requirements to establish an IPsec connection. Multiple connections can be referred to by recording them in a comma-separated list.

[Ragweed]

Phase= 1

Transport= udp

Local-address= Slippery_Internet_IP

Address= Ragweed_Internet_IP

Configuration= Default-main-mode

Authentication= mekmitasdigoat

[Slippery]

Phase= 1

Transport= udp

Local-address= Ragweed_Internet_IP

Address= Slippery_Internet_IP

Configuration= Default-main-mode

Authentication= mekmitasdigoat

These represent the sections referred to by the [PHASE 1] section above. They each describe the requirements that the peer gateway must satisfy in order to proceed to Phase 2.

Phase=1 is required because the ISAKMPD code uses the same procedures to process Phase 1 and Phase 2. It must be 1 in order for the parsing engine to recognise this as a Phase 1 connection configuration.

Transport=udp need not be specified. An SA has no need for flow control and so TCP would introduce needless overhead. Please note that some peers may be behind a firewall that doesn't let UDP traffic through. In that case both gateways would need TCP to be specified.

Local-address is the destination address of the expected incoming packets. In some cases, A gateway can be listening on different Interfaces for Phase 1 connections. In this case, only one interface is listening, therefore this is the IP of the listening interface on this peer. If the ISAKMP daemon was listening on multiple IP addresses, then this tag=value could be omitted altogether.

Address is the source IP of the expected incoming packets. This usually points to the peer gateway. In this case it is used as a requirement to establish a link of trust between the two gateways. In a case where the source IP address cannot be pre-determined then this tag would be omitted.
Configuration refers to a section below that specifies which mode and related encryption algorithm should be used to establish the link of trust between the two gateways.

Authentication is the passphrase that must be provided by the remote gateway. This is a password that must be used to establish the link of trust between the gateways. This tag is not needed if using X509 certificates. Please note that if this passphrase is changed, then the change must also be reflected in the isakmpd.policy file.

[Slippery-Ragweed]

Phase= 2

ISAKMP-peer= Ragweed

Configuration= Default-quick-mode

Local-ID= Net-Carefull

Remote-ID= Net-Badplants

[Ragweed-Slippery]

Phase= 2
ISAKMP-peer= Slippery

Configuration= Default-quick-mode

Local-ID= Net-Badplants

Remote-ID= Net-Carefull

These represent the sections referred to by the [PHASE 2] section above. They contain the conditions that must be met to establish an IPsec SA between the two gateways, and furthermore establish an IPsec connection. Note that multiple IPsec connections can be established between two ISAKMP SAs.

Phase=2 is required because the ISAKMPD configuration engine uses the same code to parse Phase 1 and Phase 2 connections. This tag is always required.

ISAKMPD-Peer reflects the information in the square brackets above, and that describes a Phase 1 connection. The IPsec connection can only be established with a gateway that has passed the criteria of a Phase 1 connection.

Configuration refers to the section in the square brackets that describes the encryption algorithm, key lifetime value, and key length to use between the two gateways.

Local-ID refers to the information in the square brackets below (NET-Badplants) that describes the private network behind the local host to the peer gateway. This is the portion that is passed on so that the other gateway can set up the proper routing table to transfer data over the VPN to this network.

Remote-ID refers to the information in the square brackets below (NET-Carefull) that describes what kind of network or address to expect to receive from the remote host. If this cannot be pre-determined, it doesn’t need to be included.

[NET-Badplants]

ID-type= IPV4_ADDR_SUBNET

Network= Badplants_Private_Network_Address

Netmask= Badplants_Private_Subnet_Mask

[NET-Carefull]

ID-type= IPV4_ADDR_SUBNET

Network= Carefull_Private_Network_Address

Netmask= Carefull_Private_Subnet_Mask

These two sections are in the conf file of each host. They are the sections referenced by the Local-ID and Remote-ID of the <IPSEC-CONNECTION> section. They describe the routes that should be set up to allow traffic from one private network to another. The values contained in these two sections are analogous to the Unix command ‘route add Remote_Network/Remote_subnet Remote_gateway’

ID-type= can be IPV4_ADDR_SUBNET or IPV4_ADDR (RFC2708 mentions more possible values). Depending on which is chosen, the following two tags may or may not be used. IPV4_ADDR_SUBNET is discussed in this case, as it is a LAN to LAN configuration that is being established.

[Default-main-mode]

DOI= IPSEC

EXCHANGE_TYPE= ID_PROT

Transforms= 3DES-SHA

This section describes the requirements for the encryption methods of Phase 1 connections.

As seen here, the Domain of Interest (DOI) is stated as being IPSEC.

The EXCHANGE_TYPE variable is set to ID_PROT for Phase 1, which states that the information from the sending gateway will be presented using the main mode scenario. To change to aggressive mode, copy-paste this section and rename the section [default-aggressive-mode].

Transforms is the transforms required (or expected) for this exchange. The value points to a section in the configuration file that establishes the parameters for this transform. In this case, a packet encrypted with 3DES and a checksum verifiable with SHA is expected. There are many different transforms defined inside the sample VPN-east.conf for Phase 1. Feel free to use the transform that is most appropriate for the situation. Note that some legal issues may arise depending on the transform chosen. If different transforms are needed by different ISAKMP connections, then this section should be copy-pasted and renamed appropriately. This requires that the ISAKMP connection be changed to refer to the newly named section instead.

[Default-quick-mode]

DOI= IPSEC

EXCHANGE_TYPE= QUICK_MODE

Suites= QM-ESP-3DES-SHA-PFS-SUITE,QM-ESP-DES-MD5-PFS-SUITE

This section describes the requirements for the encryption of the data to be sent through the IPsec connection above. Note the difference between this section and the Phase 1 equivalent just above is that the EXCHANGE_TYPE is QUICK_MODE. Quick mode should always be used in Phase 2 connections.

Suites refers to sections describing the different encryption schemes available between the two hosts. There are predefined suites in the sample isakmpd.conf file. Since AH was not enabled in sysctl.conf, no suites using AH should be specified. The use of Perfect Forward Secrecy is suggested as this generates session keys that are totally independent from each other. This means that even if somebody captures multiple session keys, they will not be able to derive the next key to be used from those captured.

Though there is much more to be said about ISAKMP and Ipsec, using the above basic descriptions should allow you to create a simple but solid VPN that cares for and feeds itself.

Note that the Suites and Transforms were not included in this document. These are of importance if the ISAKMP SA is to be established using public key and X509 certificates and if the IPsec connection should be changed from TUNNEL to TRANSPORT.

This is the exciting part. It is suggested you use

$ isakmpd -d -DA=99
The first time that this daemon is run. The daemon will not be running in daemon mode but as a regular process. It will log everything to console (stdout and stderror for you programmers out there). This will cause a million things to pop up on the screen. Read them all and try to interpret the information. It's fun, and a great learning experience too!

If all went well, switch to another terminal and the execute the following on the Slippery host:
$netstat —rn

Routing tables

Internet:

Destination Gateway Flags Refs Use Mtu Interface

Encap:

Source Port Destination Port Proto SA(Address/SPI/Proto)

0.0.0.0/32 0 Badpl_Priv_Net 0 0 Ragweed_INET_IP/SPI/50

Extern_Priv_Net 0 BadPl_Priv_Net 0 0 Ragweed_INET_IP/SPI/50

And the opposite should be observed from the Ragweed host.

At this point a PING from Dandelion to Icy should confirm that the VPN works. To complete this scenario, the Laser Printer on the Carefull.com network was installed on the Badplants.com workstations.

If all has worked well, edit the /etc/rc.conf file to have isakmpd=YES. This will bring up the VPN whenever OBSD is rebooted.

To stop the ISAKMPD daemon
$ps -ax | grep -i isakmpd
Take the PID number and
$kill PID
Then flush the IPsec routes using
$ipsecadm flush
The ENCAP: portion of
$netstat -rn
should now be blank,
$netstat -an
should not display UDP 500 listening anymore either.

The finished files are available at

If something didn't work, don't despair. First, look back at the configuration file for typos. Then there are a few things you can try:
From Slippery:
Verify that there is a Phase 1 transfer going through:
$ tcpdump -i EXT_IFACE host RAGWEED and port 500'
or
$tcpdump -v -s1500 port 500
The first will show any data coming or going to Ragweed on port 500-- which is the key exchange port. Start/Stop ISAKMPD on one end and verify that there is traffic. If there is traffic and ISAKMPD does not return anything, then the problem probably lies in the routing (Either Phase 2 or actual routing in your network).

The second will display the clear text parts of IKE. You should be able to tell most of what happens during the main mode transfer with this. (For a reference of what is supposed to happen, see section 4 of RFC2708).
If you get NO_PROPOSAL_CHOSEN, this means that one end is not meeting the requirements you have set up for the Phase 1 peer section. Verify your setup and the connection.

If you get nothing at all then try pinging RAGWEED from SLIPPERY. You may be experiencing a network outage of sorts. Unfortunately, although it is fairly powerful, a ISAKMP daemon cannot fix network outages!

Verify that there is ESP traffic between the two hosts

Then switch to another console and ping Dandelion. Switch back to the console that is displaying the TCPDUMP. You should see some traffic. If it is not coming back, check that the ENCAP: routes are correct on both ends. If they are not, then you have not entered them properly in your conf file.

This section is open to discussion. Several scenarios are possible. The following are but a few examples of what the author has experienced.

The following are the screenshots of the configurations in the Axent RaptorModile program.

This is the initial logon screen for Raptor. The username and password here are local to the client computer. This is mainly to stop a non-authorised user of the client computer to establish and IPsec link.

This is the initial screen that is presented. Create a new ISAKMP gateway by using the New button.

Enter the USER_FQDN ID that is expected to be presented by the OpenBSD VPN gateway and select an IKE policy that will be accepted by the Default-aggressive-mode-weak of the OpenBSD VPN Gateway. Click OK to close the screen, then again at the previous screen. Select the new gateway and click on the Tunnels button

This presents the configured tunnels for this particular gateway. Select New.

Enter the subnet and subnet mask you are connecting to. The Tunnel Name here is irrelevant. Then, create a VPN policy that matches up with a Quick Mode suite acceptable to your OpenBSD VPN Gateway

Note that the Diffie-Hellman group one corresponds to MODP_768 and group 2 to MODP_1024. When this is done you should have the following screen:

Now go back to the main screen and select Port Control

The port control type seems to be some sort of Firewalling. Select Wide Open (the others seem to enable some Microsoft/Raptor specific attributes such as bridging NetBIOS traffic and the like). Then select the Options tab.

This screen is for debugging. Note that if the negotiation fails make sure you run TCPDUMP. The reason for this is that the client does not always delete the ISAKMP gateway information even though it is not connected. This means that it will try and establish a tunnel between two unestablished ISAKMP SAs. In this case, you will need to remove the route pointing to the OpenBSD gateway and maybe even kill the VPND and ISAKMPD services running under NT. I don’t know why this is so buggy; I’ve had to wrestle with this under NT. Perhaps someone could provide me with details as to how to make RaptorMobile renegotiate the IKE whenever it disconnects and reconnects.

I will not post the logs for the RaptorMobile but trust me when I say that they do nicely demonstrate how ISAKMPD works.

Now for the OpenBSD side of things:

[General]

Retransmits= 5

Exchange-max-time= 120

Listen-on= 192.168.100.240

# 192.168.100.240 is the external IP address of the OBSD VPN Gateway

# Incoming phase 1 negotiations are multiplexed on the source IP address

[Phase 1]

Default= SecureOps

[Phase 2]

Passive-connections= Raptor-Server

[SecureOps]

Phase= 1

Transport= udp

Configuration= Default-aggressive-mode-weak

# ISAKMPD has been changed in 2.7 so that a USAR_FQDN that is presented using Aggressive

# mode will iterate through the list of Phase 1 connections until a section containing

# that USER_FQDN is met.

[drbones@secureops]

Phase= 1

Transport= udp

Local-address= 192.168.100.240

Configuration= Default-aggressive-mode-weak

Authentication= 12345678901234567890

ID= MyID

[MyID]

ID-type= USER_FQDN

Name= vpn@secureops

[RaptorNT-Server]

Phase= 2

ISAKMP-peer= drbones@secureops

Configuration= Default-quick-mode

Local-ID= Net-INT

[Net-INT]

ID-type= IPV4_ADDR_SUBNET

Network= 10.0.0.0

Netmask= 255.255.255.0

# Phase 1 descriptions

[Default-aggressive-mode-weak]

DOI= IPSEC

EXCHANGE_TYPE= AGGRESSIVE

Transforms= DES-MD5

# AGGRESSIVE mode is needed in order to establish a Phase 1 connection that uses USER_FQDN

# Main mode transforms

######################

# DES

[DES-MD5]

ENCRYPTION_ALGORITHM= DES_CBC

HASH_ALGORITHM= MD5

AUTHENTICATION_METHOD= PRE_SHARED

GROUP_DESCRIPTION= MODP_1024

Life= LIFE_10_MINUTES

# MODP_1024 corresponds with Diffie-Hellman group 2 in the Raptor Policies

# Quick mode description

########################

[Default-quick-mode]

DOI= IPSEC

EXCHANGE_TYPE= QUICK_MODE

Suites= QM-ESP-DES-MD5-PFS-SUITE

# Quick mode protection suites

##############################

# DES

[QM-ESP-DES-PFS-SUITE]

Protocols= QM-ESP-DES-PFS

# Quick mode protocols

# DES

[QM-ESP-DES-MD5-PFS]

PROTOCOL_ID= IPSEC_ESP

Transforms= QM-ESP-DES-MD5-PFS-XF

# Quick mode transforms

# ESP DES+MD5

[QM-ESP-DES-MD5-PFS-XF]

TRANSFORM_ID= DES

ENCAPSULATION_MODE= TUNNEL

GROUP_DESCRIPTION= MODP_1024

AUTHENTICATION_ALGORITHM= HMAC_MD5

Life= LIFE_10_MINUTES

# Life configurations

[LIFE_10_MINUTES]

LIFE_TYPE= SECONDS

LIFE_DURATION= 64800

# 64800 corresponds to 10 minutes which is specified in the RaptorMobile configurations.

# Certificates stored in PEM format

[X509-certificates]

CA-directory= /etc/isakmpd/ca/

Cert-directory= /etc/isakmpd/certs/

Private-key= /etc/isakmpd/private/local.key

Special thanks to Angelos Keromytis who helped me get through my first experience with ISAKMP on OpenBSD.

Matthew Patton (From netsec.net) and HÂkan Olsson who helped me verify the accuracy of the information provided and supplied a few words of their own.

Series Editor: Jesse Corbeil