Rechnernetze

OpenBSD Documentation Examples for IPsec Interoperability

Example of Scenario 1 for IPsec on OpenBSD

The following is a typical gateway-to-gateway VPN that uses a preshared secret for authentication.

Gateway A connects the internal LAN 10.5.6.0/24 to the Internet. Gateway A's LAN interface has the address 10.5.6.1, and its WAN (Internet) interface has the address 14.15.16.17.

Gateway B connects the internal LAN 172.23.9.0/24 to the Internet. Gateway B's WAN (Internet) interface has the address 22.23.24.25. Gateway B's LAN interface address, 172.23.9.1, can be used for testing IPsec but is not needed for configuring Gateway A.

The IKE Phase 1 parameters used in Scenario 1 are:

Main mode
TripleDES
SHA-1
MODP group 2 (1024 bits)
pre-shared secret of "hr5xb84l6aa9r6"
SA lifetime of 28800 seconds (eight hours) with no kbytes rekeying

The IKE Phase 2 parameters used in Scenario 1 are:

TripleDES
SHA-1
ESP tunnel mode
MODP group 2 (1024 bits)
Perfect forward secrecy for rekeying
SA lifetime of 3600 seconds (one hour) with no kbytes rekeying
Selectors for all IP protocols, all ports, between 10.5.6.0/24 and 172.23.9.0/24, using IPv4 subnets

There are three steps involved in setting up Gateway A for this scenario:

Edit the IKE parameters in /etc/isakmpd.conf

Edit the IKE policy in /etc/isakmpd.policy

Set up the IPsec flows (SPD entries)

The following subsections each explain these steps in detail. All of the configuration for IPsec in OpenBSD is done by editing text files.

OpenBSD's IPsec settings do not require that you identify the inside and outside network interfaces used. If you have not yet configured your interfaces, see the manual pages for the ifconfig command for more information.

Configuring /etc/isakmpd.conf

The /etc/isakmpd.conf file should contain the following sections:

[General]
Default-phase-2-Suites=   QM-ESP-3DES-SHA-PFS-SUITE
Default-phase-2-lifetime= 3600,3600:3600
Default-phase-1-lifetime= 28800,28800:28800

[Phase 1]
22.23.24.25=         Peer-22.23.24.25

[Peer-22.23.24.25]
Phase=   1
Address= 22.23.24.25
Authentication=  hr5xb84l6aa9r6
Configuration=   GatewayB-configuration

[GatewayB-configuration]
EXCHANGE_TYPE=  ID_PROT
Transforms=  3DES-SHA

Remember that /etc/isakmpd.conf should be owned by root and its permissions should be "600" ("-rw-------", read-write by the owner only).

Configuring /etc/isakmpd.policy

The /etc/isakmpd.policy file should contain the following section:

Authorizer: "POLICY"
Licensees: "passphrase:hr5xb84l6aa9r6"
Conditions: app_domain == "IPsec policy" && esp_present == "yes" &&
  esp_enc_alg == "3des" && esp_auth_alg == "hmac-sha" &&
  phase1_group_desc == "2" && esp_group_desc == "2" &&
  pfs == "yes" && esp_life_seconds == "3600" &&
  esp_encapsulation == "tunnel" && remote_filter_type == "IPv4 subnet" &&
  local_filter_type == "IPv4 subnet" &&
  local_filter == "010.005.006.000-010.005.006.255" &&
  remote_filter == "172.023.009.000-172.023.009.255" &&
  remote_id_type == "IPv4 address" &&
  remote_id == "022.023.024.025" &&
  remote_negotiation_address == "022.023.024.025" -> "true";

Since the /etc/isakmpd.policy file contains a passphrase, you should set the permissions to "600" ("-rw-------", read-write by the owner only). Alternatively, you can use the following Licensees line (replacing the one shown above):

Licensees: "passphrase-md5-hex:93abf2c83d65705f6906d6fd2b912483"

Doing so prevents you from entering the actual passphrase into the file.

Setting up the flows

Issue the following two commands as root:

ipsecadm flow -addr 10.5.6.0/24 172.23.9.0/24 -out -require -dst 22.23.24.25

ipsecadm flow -addr 172.23.9.0/24 10.5.6.0/24 -in -require -dst 22.23.24.25

As soon as gateway A sees any traffic with the appropriate source and destination IP addresses, it will negotiate the relevant IPsec SAs.

If you want to prohibit any other traffic in and out of Gateway A, give the commands:

ipsecadm flow -addr 0.0.0.0/0 0.0.0.0/0 -out -deny

ipsecadm flow -addr 0.0.0.0/0 0.0.0.0/0 -in -deny

The order with which the four ipsecadm flow commands are issued is not important.

To test whether traffic correctly flows between the two protected subnets, use the following command on Gateway A:

ping -I 10.5.6.1 172.23.9.1

Soon, you should be getting responses from the peer, such as:

PING 172.23.9.1 (172.23.9.1): 56 data bytes
64 bytes from 172.23.9.1: icmp_seq=0 ttl=255 time=8.486 ms
64 bytes from 172.23.9.1: icmp_seq=1 ttl=255 time=8.509 ms

To see how much traffic has moved, use the netstat -ss -p esp command. Its output will look something like:

esp:
        132298 input ESP packets
        135786 output ESP packets
        18976032 input bytes
        13895628 output bytes

To see if there are any Phase 2 SAs set up, you can read the /kern/ipsec pseudo-file. Looking at that file with the cat command shows something like:

SPI = 3d625dea, Destination = 22.23.24.25, Sproto = 50
        Established 478 seconds ago
        Source = 14.15.16.17
        Remote credential type 1
        Remote auth type 2
        Flags (00001082) = 
        Crypto ID: 2
        xform = 
                Encryption = <3DES>
                Authentication = 
        611712 bytes processed by this SA
        Last used 1 seconds ago
        Expirations:
                Hard expiration(1) in 722 seconds
                Soft expiration(1) in 602 seconds

(If your OpenBSD system doesn't have the /kern directory, give the two commands mkdir /kern and mount_kernfs /kern /kern.)

Example of Scenario 2 for IPsec on OpenBSD

The following is a typical gateway-to-gateway VPN that uses PKIX certificates for authentication. The network setup is identical to the one given in the previous scenario. The IKE Phase 1 and Phase 2 parameters are identical to the ones given in the previous scenario, with the exception that the identification is done with signatures authenticated by PKIX certificates.

There are four steps involved in setting up Gateway A for this scenario:

Edit the IKE parameters in /etc/isakmpd.conf -- this is identical to the previous scenario
Create the PKIX certificates
Edit the IKE policy in /etc/isakmpd.policy
Set up the IPsec flows (SPD entries)

The only difference between the setup for this scenario and the previous one is that you need to set up certificates, and you need to change one line in the /etc/isakmpd.policy file.

Creating the PKIX certificates

Create gateway A's RSA key and the corresponding Certificate Signing Request (CSR) with the two commands:

openssl genrsa -out /etc/isakmpd/private/local.key 1024
openssl req -new -key /etc/isakmpd/private/local.key \
    -out /etc/isakmpd/private/14.15.16.17.csr

During the second openssl command, you will be asked for information such as the country, state, locality name, and so on. Fill these in as required; note that at least on of these must be filled. Send the CSR file (/etc/isakmpd/private/14.15.16.17.csr) to your CA.

The CA will send back PKIX certificate; that file may be in the text (PEM) format, such as:

It may instead be in a binary format, containing the raw DER of the certificate. For use in OpenBSD, it must be in the text (PEM) format. To convert it to the PEM format, use the command:

openssl x509 -in certificate.raw -outform PEM -out certificate.crt

Place the certificate.crt file in the /etc/isakmpd/certs directory.

Place the CA's certificate (which also must be in PEM format) in /etc/isakmpd/ca. The file can have any name as long as it is in that directory. For this example, name the file /etc/isakmpd/ca/myca.crt

Note that the isakmpd system does not use CRLs, so there is no setup for CRL usage.

Configuring /etc/isakmpd.policy

In order to configure the /etc/isakmpd.policy file for certificates, you need to know the CA's name as it appears in the CA's certificate. To find this, give the command:

openssl x509 -in /etc/isakmpd/ca/myca.crt -text | grep Issuer

The output will be something like:

Issuer: O=Big Company, OU=Trusted Root CA

The /etc/isakmpd.policy file should look just like it did in the previous example, except that the "Licensees:" line is different. Change the line from:

Licensees: "passphrase:hr5xb84l6aa9r6"

to:

Licensees: "DN:/O=Big Company/OU=Trusted Root CA"

The rest of the setup is identical to the previous scenario.