A Mobile VPN configuration using OpenBSD and ScreenOS

Abstract

This paper explains how to configure and secure a VPN tunnel between an laptop running OpenBSD that is using a dynamic IP address and a Netscreen device with a static IP address. It covers IKE authentication using both pre-shared keys and X509 certificates.

Introduction

The goal of this solution is to provide a secure system for allowing users with dynamic IP addresses to access internal network resources. This may be a user traveling with a laptop or perhaps a telecommuter that has a DSL or cable network connection with a dynamic IP address.

For this solution, we are going to using a Netscreen device as the security gateway and OpenBSD 3.0 running on a laptop. OpenBSD is a 4.4BSD-based operating system that emphasizes portability, standardization, correctness, proactive security and integrated cryptography. It was chosen because it is "secure by default" and it provides a robust and reliable IPsec and packet filtering implementation (pf).

Netscreen is a dedicated hardware firewall that runs a proprietary operating system called ScreenOS. ScreenOS can be configured in three different ways: command line, a web interface and a Windows GUI program. In this paper, I will give the command line interface instructions for configuring the device. For this test, I ran ScreenOS version 2.6.1r7.

The network topology for this system looks like the following:


   OpenBSD
   Roaming ----- Internet ----- Netscreen ------ private network
   Laptop                                        192.168.3.0/24

      dynamic ip           untrust ip   trust ip
                           24.0.73.58  192.168.3.1

We will construct two different types of VPN tunnels. The first will use IKE authentication using pre-shared keys (essentially a static passphrase) and the second will use X509 certificates for authentication.

Background on IKE

Using IPsec, there are two primary methods to create a Security Association (SA) between any two parties. The first is called manual key and it involves manually selecting a security parameter index (SPI), encryption parameters and static encryption keys and then configuring that information on all hosts and security gateways.

The second is automatic keying which involves a key management protocol. The most popular key management protocol is Internet Key Exchange (IKE). IKE is really a hybrid protocol involving Internet Security Association and Key Management Protocol (ISAKMP) and Oakley and SKEME. IKE is specified in RFC 2409.

IKE is implemented in OpenBSD via the isakmpd(8) IKE key management daemon and is implemented via ScreenOS in the Netscreen device. In order to learn how isakmpd and ScreenOS interoperate, the first step was to setup an IKE connection with pre-shared keys.

An important concept of IKE that will help you understand how the protocol works is that there are two primary phases of the protocol. In Phase 1, the two peers establish a secure, authenticated channel in which to communicate. This is called a Security Association (SA) and can be thought of as a bootstrap to Phase 2. In Phase 2, the two systems then decide which encryption and hash algorithms will be used for bulk encryption, negotiate keys for that cipher, etc.

IKE using Pre-Shared Keys

This section will discuss how to setup a VPN tunnel using a pre-shared key for IKE Phase I authentication. On the Netscreen side, there are a couple ways to configure the system for remote users and I will cover two of them.

Method 1: Dialup Groups

ScreenOS has the ability to create users and then associate those users with a "Dialup Group." For each user, you specify the type of IPsec keying (Auto or Manual Key), passwords and the Dialup group they are in.

The advantage of this approach is that it scales well for multiple users because you can put all similar users in one group. You can then create one IKE gateway for the group instead of one for each user.

The following commands perform the following steps:

The first command set dialup laptop-vpn creates a new dialup group named "laptop-vpn".
The next three commands create a new user named "brett" with IKE authentication, give that user an IKE ID (this will be sent by isakmpd on the laptop to uniquely identify the user) and then it enables that user.
The last command simply puts the user "brett" into the "laptop-vpn" dialup group.

ns5-> set dialup laptop-vpn
ns5-> set user brett type ike
ns5-> set user brett ike-id brett@atomicgears.com
ns5-> set user brett enable
ns5-> set dialup laptop-vpn + brett

Next, we associate that Dialup group with a IKE gateway and specify which encryption and authentication settings we want to use for Phase 1 and Phase 2.

Phase 1

In this case, for Phase 1 we use a pre-shared key of "secret" and we allow only 3DES for the encryption algorithm and SHA for the hash algorithm. Phase 1 parameters are created using the set ike gateway command:

ns5-> set ike gateway "laptop-vpn" dialup "laptop-vpn" aggressive \ preshare "secret" Proposal "pre-g2-3des-sha"

One important parameter is the use of "Aggressive" mode. It is beyond the scope of this paper to describe the different modes in Phase 1; however, the other primary mode (called Main Mode or ID Protection Mode) can only be used when both ends of the tunnel have static IP addresses or when X509 Certificates are used for authentication.

The Proposal flag is used to specify what types of authentication, encryption and hash algorithm are going to be used. ScreenOS comes pre-configured with a number of pre-defined Phase 1 proposals and I've specified pre-g2-3des-sha. You can configure and support more than one proposal. During the initial IPsec session setup, the initiator sends the proposals it wants to use and then the responder will pick one from its list of matching proposals.

The only values that might not be clear in the above proposal are pre which simply means we want to use pre-shared keys for authentication and g2 which means we want to use type "G2" for Perfect Forward Secrecy (PFS). PFS is a design property that states if one key is broken, it only effects the specific data protected by that one key. The compromised key cannot be used to derive any additional encryption keys. Group 2 defines the type of Diffie-Hellman keys used to provide PFS. Group 1 uses 768 bit keys, Group 2 uses 1024 bit keys and there is a draft proposal for longer keys. You might also see these specified as modular exponentiation group (MODP) values.

Phase 2

In ScreenOS, Phase 2 settings are specified using the set vpn command. In this case, we have specified a name for the tunnel (laptop-vpn), an ID number (similar to a rule number in a firewall filtering policy) and the other end of the tunnel (the previously defined Phase 1 gateway named laptop-vpn):

Similar to Phase 1, we also specify a proposal for Phase 2. This proposal uses Group 2 (1024 bit DH keys) for PFS, ESP for the IPsec mode (as opposed to Authentication Header (AH) mode), 3DES for encryption and SHA for the hashing algorithm. We also specify "tunnel" mode as opposed to transport mode.

ns5-> set vpn "laptop-vpn" id 3 gateway "laptop-vpn" no-replay \ tunnel idletime 0 proposal "g2-esp-3des-sha"

The final two commands create a network object for our internal network and then establish a VPN tunnel associating the dialup group with a specific Phase 2 VPN setting (laptop-vpn).

ns5-> set address trust "internal" 192.168.3.0 255.255.255.0 ns5-> set policy id 2 name "laptop-vpn" incoming "Dial-Up VPN" \ "internal" "ANY" Tunnel vpn "laptop-vpn" id 4 log

Method 2: Dynamic IP

This approach works fine for small numbers of remote users; however, since there is a requirement to either create a new tunnel for each user or give all users the same "Peer ID", it doesn't scale well.

The commands below are similar to the above so I won't explain them in-depth as before. The key is that the other end of the Phase 1 negotiation can be any IP address due to the set ike gateway ... ip 0.0.0.0 command. The other end of the tunnel is identified not through an IP address but instead through a user fully qualified domain name (UFQDN) of "brett@atomcigears.com". When the laptop sends an identification message during Phase 1, it will send that ID string so the Netscreen will know which IKE parameters to use. The use of UFQDN as an identification data type is defined in RFC2047.

ns5-> set ike gateway "dynamic-vpn" ip 0.0.0.0 id "brett@atomicgears.com" \ aggressive preshare "secret" proposal "pre-g2-3des-sha" ns5-> set vpn "dynamic-vpn" gateway "testvpn" replay tunnel \ proposal "g2-esp-3des-sha" ns5-> set policy id 4 name "dyn-ip-vpn" incoming "Outside Any" \ "internal" "ANY" Tunnel vpn "dynamic-vpn" id 4 log

OpenBSD Configuration

The OpenBSD laptop uses isakmpd(8) to perform IKE authentication and keynote(1) to enforce a policy. The two configuration files are isakmpd.conf and isakmpd.policy.

Following is a sample isakmpd.policy KeyNote assertion stating that ESP must be used for Phase 1, the encryption algorithm must be 3DES and that SHA must be used for the hash algorithm.

Note: The sample OpenBSD configuration file has esp_enc_alg = "aes" which will result in a NO_PROPOSAL_CHOSEN message since we specified 3DES on the Netscreen and the Netscreen doesn't support AES at this point. I've modified the policy to accept ESP encryption with 3DES. Also note that you need to specify the proper pre-shared key.

KeyNote-Version: 2 Comment: Accept ESP SAs from a remote that uses the right password Authorizer: "POLICY" Licensees: "passphrase:secret" Conditions: app_domain == "IPsec policy" && esp_present == "yes" && esp_enc_alg == "3des" && esp_auth_alg == "hmac-sha" -> "true";

The isamkpd.conf configuration file is strait forward. Refer to isakmpd.conf(5) if you don't understand it. The only thing to note is that the sample isakmpd.conf file has the Phase I EXCHANGE_TYPE=ID_PROT which doesn't work with Dynamic IP addresses and pre-shared keys so we need to change it to Aggressive mode.

[General] Retransmits= 5 Exchange-max-time= 120 # # IKE Phase I Settings # [Phase 1] 24.0.73.58= NS5 [NS5] Phase= 1 Transport= udp Address= 24.0.73.58 Configuration= main-mode Authentication= secret ID= myname [main-mode] DOI= IPSEC EXCHANGE_TYPE= AGGRESSIVE Transforms= 3DES-SHA [myname] ID-type= USER_FQDN Name= brett@atomicgears.com # # IKE Phase 2 Settings # [Phase 2] Connections= laptop-homenet [laptop-homenet] Phase= 2 ISAKMP-peer= NS5 Configuration= quick-mode Local-ID= my-ipv4-addr Remote-ID= ns5-ipv4-net [my-ipv4-addr] ID-type= IPV4_ADDR_SUBNET Network= 0.0.0.0 Netmask= 0.0.0.0 [ns5-ipv4-net] ID-type= IPV4_ADDR_SUBNET Network= 192.168.3.0 Netmask= 255.255.255.0 [quick-mode] DOI= IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-PFS-SUITE

OpenBSD Hints/Help

Be very careful with the syntax in the configuration files. If you have extra spaces, tabs, etc. after values in the configuration file it won't work (this has been fixed by a recent patch in -current). You can look at some of the IPsec info by mounting the kern filesystem:

# mount -t kernfs /kern /kern
# more /kern/ipsec
Hashmask: 31, policy entries: 2
SPI = c8bbba95, Destination = 24.0.73.58, Sproto = 50
        Established 322 seconds ago
        Source = 24.0.73.59
        Flags (00011082) = 
        Crypto ID: 3
        xform = 
                Encryption = <3DES>
                Authentication = 
        110348 bytes processed by this SA
        Last used 2 seconds ago
        Expirations:
                Hard expiration(1) in 878 seconds
                Soft expiration(1) in 758 seconds

You can also use tcpdump -vv -n -s1500 udp port 500 to see the IKE negotiations.

Note that the routing table will get setup automatically. In this case, you can see that the local machine will encapsulate all traffic going to the internal network behind the Netscreen, 192.168.3.0/24.

# netstat -rn -f encap
Routing tables

Encap:
Source             Port  Destination        Port  Proto SA(Address/Proto/Type/Direction)
192.168.3/24       0     0/0                0     0     24.0.73.58/50/use/in
0/0                0     192.168.3/24       0     0     24.0.73.58/50/require/out

Netscreen Hints/Help

On the Netscreen, you can get detailed debug messages from ScreenOS using the debug facility. Enter the first two commands, start a IKE session, then use the third command to see the detailed debug messages.

ns5-> debug ike detail
ns5-> clear dbuf
ns5-> get dbuf stream

If you want to see debug messages stream on the console in real-time, you can use the following commands:

ns5-> unset console dbuf
ns5-> set console page 0

If you wish to re-enable console paging, use the following:

ns5-> set console page 24
ns5-> set console dbuf

Finally, if you want to turn off debugging, you can either turn off a specific debug or turn off all debugging:

ns5-> undebug ike detail
ns5-> undebug all

Filtering Traffic

On the Netscreen gateway, we probably want to limit what protocols are allowed through to the inside network. Here is an example of how to do that. In this case, I will create a group of protocols we want to allow (named "inbound-vpn") and then specify that POP3, SSH and ping are allowed through the tunnel:

ns5-> set group service "inbound-vpn-svc" comment " " ns5-> set group service "inbound-vpn-svc" add "PING" ns5-> set group service "inbound-vpn-svc" add "POP3" ns5-> set group service "inbound-vpn-svc" add "SSH" ns5-> set policy id 5 name "dialup-vpn" incoming "Dial-Up VPN" \ "internal" "inbound-vpn-svc" Tunnel vpn "dialup-vpn" id 7

The inbound-vpn in the above configuration is the part of the policy that limits which services are allowed through the tunnel.

There are some problems with doing this (if you set port/protocol on the OpenBSD side, the Netscreen doesn't seem to do the right thing). However, if on the Netscreen, you turn off policy checking, you will be able to get it to work:

ns5-> unset ike policy-checking

The following warning is given:

WARNING: Policy checking is disabled and only one policy can be set per Gateway.
         If more than one policy is desired per Gateway, policy checking must first be
         enabled by executing the 'set ike policy-checking' command.

I have tested that only the specific protocols listed in the policy are allowed through the gateway. The basic limitation is that you cannot have multiple different policies between the same two gateways if you turn off policy checking.

Using X509 Certificates for Phase 1 Authentication

Now that we understand the basics of an OpenBSD to Netscreen VPN using pre-shared keys with IKE, we can setup and use X509 certificates for authentication. The primary difference between these steps and those presented in the examples in the isakmpd(8) man page is that we need to use the Certification Authority (CA) capabilities of OpenSSL so that we can generate Certificate Revocation Lists (CRLs) for the Netscreen device. ScreenOS will not perform authentication via X509 certificates without a CRL.

One big advantage of using X509 certificates for authentication is that we can potentially use Main Mode for Phase 1 thus keeping identities secret (Aggressive Mode sends your identity in the clear). However, there is a small price to pay. The Netscreen manual states "When a dialup VPN user negotiates an AutoKey IKE tunnel with a preshared key, Aggressive mode must be used." Even though we are using certificates instead of a preshared key, the same limitation applies. In my testing, I have found that anytime you define an IKE gateway with a Dial-Up user or group, ScreenOS will request a certificate type 0 (None) which isakmpd rejects with a "CERT_TYPE_UNSUPPORTED" message. This occurs even if you tell ScreenOS to request a x509 cert type.

Practically, this means we have two choices when using X509 certificates with a Netscreen:

Use a Dialup Group with Aggressive Mode.
The advantage with this approach (as detailed above) is scalability. You don't have to create a new IKE tunnel and rule for each VPN tunnel. Practically, there isn't much more security than a preshared key and the complexity of certificates probably outweigh any potential advantage.

Configure a Dynamic IP with Main Mode.
The advantage is identity protection while the disadvantage is complexity of configuration for large-scale deployments. Note that you could give everybody a different certificate and use a common ID thus requiring only one IKE tunnel configuration and one VPN rule. However, in this case, accounting of user traffic is decreased.

In this paper, I will use the first approach. If you want to use the second approach, it is pretty similar and nothing on the OpenBSD side or in the certificate process changes. I will note the different ScreenOS commands for Main Mode where appropriate.

Before getting started, here is an overview of the basic steps:

Create the CA key and certificate
Generate a Certificate Signing Request (CSR) on the Netscreen
Export the CSR, sign with the CA
Modify the Netscreen cert using OpenBSD certpatch(8)
Generate a CSR for the OpenBSD laptop
Sign the OpenBSD laptop CSR
Modify the laptop cert using certpatch(8)
Generate a Certificate Revocation List (CRL)
Install the CA cert, the Netscreen cert, and the CRL on the Netscreen
Install the CA cert, private key, and OpenBSD cert on the laptop

I'm not going to provide a lot of details on setting up the openssl.cnf file or any of the other CA steps since they are covered elsewhere. I will provide a brief overview and I have abbreviated the output from the OpenSSL commands to make things easier to read.

Create the CA infrastructure

First, create a 1024 bit RSA key pair (note that I have chosen to protect the CA private key with 3DES encryption), then a CSR, and then self-sign:

# openssl genrsa -des3 -out /etc/ssl/private/ca.key 1024 # openssl req -new -key /etc/ssl/private/ca.key -out /etc/ssl/private/ca.csr # openssl x509 -req -days 730 -in /etc/ssl/private/ca.csr \ -signkey /etc/ssl/private/ca.key -extfile /etc/ssl/x509v3.cnf \ -extensions x509v3_CA -out /etc/ssl/ca.crt

Create the Netscreen Keys/Certs

The following ScreenOS commands will set the correct DN and parameters for the Netscreen CSR and then output the actual CSR. You can cut and paste the CSR.

ns5-> set pki x509 dn country-name "US" ns5-> set pki x509 dn org-name "Atomic Gears LLC" ns5-> set pki x509 dn org-unit-name "VPN" ns5-> set pki x509 dn name "24.0.53.78" ns5-> get pki x509 dn ns5's X509 Distinguish Name: C =US O =Atomic Gears LLC OU=VPN CN=24.0.53.78 CN=22000060 CN=ns5 CN=rsa-key ns5-> exec pki rsa new-key 1024 ns5-> exec pki x509 pkcs10

Next, transfer the CSR to your CA system, sign it and modify it to add the SubjAltName:

# openssl ca -md sha1 -days 730 -in /tmp/24.0.73.58.csr \ -out /etc/ssl/certs/24.0.73.58.crt Using configuration from /etc/ssl/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'US' organizationName :PRINTABLE:'Atomic Gears LLC' organizationalUnitName:PRINTABLE:'VPN' commonName :PRINTABLE:'22000060' commonName :PRINTABLE:'24.0.73.58' commonName :PRINTABLE:'rsa-key' commonName :PRINTABLE:'ns5' Certificate is to be certified until Mar 26 17:56:59 2004 GMT (730 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated # certpatch -i 24.0.73.58 -k /etc/ssl/private/ca.key \ /etc/ssl/certs/24.0.73.58.crt /etc/ssl/certs/24.0.73.58.crt Reading ssleay created certificate /etc/ssl/certs/24.0.73.58.crt and modify it Enter PEM pass phrase: Creating Signature: PKEY_TYPE = RSA: X509_sign: 128 OKAY Writing new certificate to /etc/ssl/certs/24.0.73.58

At this point, you can transfer the CA certificate and the Netscreen cert to the Netscreen device via either TFTP or using the web GUI.

Create the OpenBSD Laptop Keys/Certs

For the OpenBSD laptop, we need to create a new RSA keypair, a CSR and then have the CA sign it.

There is a critical decision to be made here. By default, the private key will not be protected with a passphrase. If you want to protect it, you must use the -des3 flag to the OpenSSL command. However, with the increase in security there is a decrease in usability. Isakmpd has no way to query for the passphrase unless you run with the -d flag. And, each time Phase I negotiations occur, you need to re-enter the passphrase.

I have decided to protect my keys and live with the manual passphrase entry requirement. The steps below will create the key and the CSR. Note that we put the RSA private key into the /etc/iskampd/private directory.

# openssl genrsa -des3 -out /etc/isakmpd/private/local.key 1024 # openssl req -new -key /etc/isakmpd/private/local.key \ -out /etc/isakmpd/private/brett@atomicgears.com.csr US []:US Atomic Gears LLC []:Atomic Gears LLC Common Name (eg, fully qualified host name) []:. info@atomicgears.com []:brett@atomicgears.com

Next, sign the CSR and modify it. The key is to use certpatch(8) with the -t UFQDN flag and supply your email address. This is how the Netscreen will identify your tunnel and how isakmpd will know which cert to use (remember the ike-id string in the ScreenOS set user command.

# openssl ca -md sha1 -days 365 \ -in /etc/isakmpd/private/brett\@atomicgears.com.csr \ -out /etc/ssl/certs/brett@atomicgears.com.crt Using configuration from /etc/ssl/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'US' organizationName :PRINTABLE:'Atomic Gears LLC' emailAddress :IA5STRING:'brett@atomicgears.com' Certificate is to be certified until Mar 27 17:34:27 2003 GMT (365 days) Sign the certificate? [y/n]:y # certpatch -t UFQDN -i brett@atomicgears.com \ -k /etc/ssl/private/ca.key /etc/ssl/certs/brett\@atomicgears.com.crt \ /etc/ssl/certs/brett\@atomicgears.com.crt

Copy the following files into the isakmpd directory (your cert, the Netscreen cert and the CA cert):

# cp brett\@atomicgears.com.crt /etc/isakmpd/certs/
# cp 24.0.73.58.crt /etc/isakmpd/certs/
# cp ca.crt /etc/isakmpd/ca/

Certificate Revocation List

The Netscreen will not use X509 certificates for authentication without a CRL. Therefore, we need to use OpenSSL to generate a CRL and then transfer that CRL to the Netscreen via TFTP or the web GUI.

# openssl ca -gencrl -crldays 30 -out /etc/ssl/crl/newcrl.crl

Note: The Netscreen software incorrectly parses CRL lists (at least those generated by OpenSSL. The Netscreen does a "Normalization" of the certificate and strips out headers. However, it strips too much. Therefore, modify the CRL as follows:

Before modification:

After modification (remove the BEGIN/END headers and add a line-break at the top of the file):


MIIBIDCBijANBgkqhkiG9w0BAQQFADBbMQswCQYDVQQGEwJVUzEZMBcGA1UEChMQ
QXRvbWljIEdlYXJzIExMQzEMMAoGA1UECxMDVlBOMSMwIQYJKoZIhvcNAQkBFhRp
bmZvQGF0b21pY2dlYXJzLmNvbRcNMDIwMzI3MTc1OTUyWhcNMDIwNDI2MTc1OTUy
WjANBgkqhkiG9w0BAQQFAAOBgQDEBh6mN3YTy3Tx4Z67ruIzm1086g/aByIradNQ
ZL/5wqBPD4sHpUlHp7roA4DQkYEt107dDZTLXIxsoR/jjABD1PN8u05pJirAnm6S
n7KtApT4Bgn6xQ48wwLzVBx/mN/zejapWbyiML6HbNYJPbx5NEHCadOWLWr6AuUh
g2yDxQ==

After you load the CRL, you should get a message in the Event log similar to:

netscreen: Successfully loaded X509 CRL file: flash:cacrl.crl

Configure the Netscreen

We must next configure the IKE gateway and policy on the Netscreen. Similar to the configuration for pre-shared keys, we will configure a user and a group for dial-in VPN users.

ns5-> set user "brett" ike-id "brett@atomicgears.com" ns5-> set user "brett" type ike ns5-> set user "brett" "enable" ns5-> set dialup "dialup-vpn-grp" + "brett" ns5-> set ike gateway "dialup-vpn-gw" dialup "dialup-vpn-grp" Aggr \ local-id "24.0.73.58" proposal "rsa-g2-3des-sha" ns5-> set ike gateway "dialup-vpn-gw" cert peer-cert-type x509-sig ns5-> set vpn "dialup-vpn" id 3 gateway "dialup-vpn-gw" replay \ tunnel idletime 0 proposal "g2-esp-3des-sha" ns5-> set vpn "dialup-vpn" monitor ns5-> set policy id 5 name "dialup-vpn" incoming "Dial-Up VPN" \ "internal" "ANY" Tunnel vpn "dialup-vpn" id 4 ns5-> set ike gateway "dynip-phase1" cert my-cert "1" ns5-> set ike gateway "dynip-phase1" cert peer-ca "1"

Note that we have specified Aggressive mode in the above configuration and that we have used the more scalable (but potentially less secure) dialup-group approach. Also important to note is that we have specified a local-id of the external IP address of the Netscreen. The reason we have done this is that this is what isakmpd uses to find the correct certificate of the peer (we specified the Netscreen IP in the SubjAlt field when using certpatch.

The cert-peer-type x509 instruction tells ScreenOS that when it sends a CERT REQEUST message to the laptop, it should ask for a x509 signature cert (type 4 in RFC2408, Section 3.9).

The last two commands specify which certificate we want to use for the Netscreen and which certificate to use for the CA certificate. The number following the command is the certificate number as shown by:

ns5-> get pki x509 list cert

ID      X509 Certificate Subject Distinguish Name
========================================================================
0       Email=info@atomicgears.com,OU=VPN,O=Atomic Gears LLC,C=US,
        Expire on 03-26-2004, Issued By:
        Email=info@atomicgears.com,OU=VPN,O=Atomic Gears LLC,C=US,
1       CN=ns5,CN=rsa-key,CN=24.0.53.78,CN=22000060,CN=24.0.73.58,OU=VPN,
        O=Atomic Gears LLC,C=US,
        Expire on 03-27-2004, Issued By:
        Email=info@atomicgears.com,OU=VPN,O=Atomic Gears LLC,C=US,
=========================================================================

If you notice, I specified a certificate of "1" for the CA even though the ID in the above command is "0". ScreenOS seems to have a bug (using the real ID of 0 doesn't work) and I have filed a bug report.

If you perform a get conf you will notice that the certificates are actually identified by their hashes. Based on the length (40 hex characters = 160 bits), I think that they are SHA1 hashes. However, when I use OpenSSL to print out the SHA and SHA1 hash of the certificates, they don't match, so I'm not sure how ScreenOS is calculating the hash they use.

set ike gateway "dynip-phase1" cert my-cert-hash 80DD624128C4985D7D27217B06BD6369163078AF
set ike gateway "dynip-phase1" cert peer-ca-hash CF10E64AAA75338E1EAB3518690BE44D403D653F

If you want to use the more secure Main Mode with a Dynamic IP tunnel, here is what the ScreenOS configuration would look like:

ns5-> set ike gateway "dynamic-ip-vpn" ip 0.0.0.0 id \ "brett@atomicgears.com" Main local-id "24.0.73.58" \ proposal "rsa-g2-3des-sha" ns5-> set ike gateway "dynamic-ip-vpn" cert peer-cert-type x509-sig ns5-> set vpn "dynamic-ip" id 6 gateway "dynamic-ip-vpn" replay \ tunnel idletime 0 proposal "g2-esp-3des-sha" ns5-> set policy id 6 name "dynip-vpn" incoming "Outside Any" \ "internal" "ANY" Tunnel vpn "dynamic-ip" id 7 ns5-> set ike gateway "dynip-phase1" cert my-cert "1" ns5-> set ike gateway "dynip-phase1" cert peer-ca "1"

Configure the OpenBSD Laptop

Essentially, using X509 certificates is almost like using pre-shared keys with user FQDN. We have added the UFQDN to the Cert in the SubjAltName field and this is exactly how isakmpd knows which cert to use. Below is the isakmpd.conf and isakpmd.policy files along with a directory listing showing the certs.

Note that the Transforms for Phase 1 now specifies RSA signatures for authentication instead of pre-shared keys. Also, if you want to use the more secure Main Mode configuation, the only change you need to make on the OpenBSD side is to set the EXCHANGE TYPE to ID_PROT.

# # General configuration # [General] Retransmits= 5 Exchange-max-time= 120 [X509-certificates] CA-directory= /etc/isakmpd/ca/ Cert-directory= /etc/isakmpd/certs/ Private-key= /etc/isakmpd/private/local.key # # Phase I. Note that the USER_FQDN value must match the SubjAltName # field and that the IPV4_ADDR for the remote gateway must match the # SubjAltName field as well. # [Phase 1] 24.0.73.58= NS5 [NS5] Phase= 1 Transport= udp Address= 24..73.58 Configuration= main-mode ID= myname [myname] ID-type= USER_FQDN Name= brett@atomicgears.com [ns5name] ID-type= IPV4_ADDR Address= 24.0.73.58 [main-mode] DOI= IPSEC EXCHANGE_TYPE= AGGRESSIVE Transforms= 3DES-SHA-RSA_SIG # note the RSA_SIG # # Phase 2 Configuration # [Phase 2] Connections= laptop-homenet [laptop-homenet] Phase= 2 ISAKMP-peer= NS5 Configuration= quick-mode Local-ID= my-ipv4-addr Remote-ID= ns5-ipv4-net [my-ipv4-addr] ID-type= IPV4_ADDR_SUBNET Network= 0.0.0.0 Netmask= 0.0.0.0 [ns5-ipv4-net] ID-type= IPV4_ADDR_SUBNET Network= 192.168.3.0 Netmask= 255.255.255.0 [quick-mode] DOI= IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-PFS-SUITE

The policy below, implemented by isakmpd.policy, allows anybody that has a cert signed by the CA to connect to us. It requires the use of ESP and 3DES for encryption along with PFS.

KeyNote-Version: 2 Comment: Allow anybody with a cert signed by our CA Authorizer: "POLICY" Licensees: "DN:/C=US/O=Atomic Gears LLC/OU=VPN/Email=info@atomicgears.com" conditions: esp_present == "yes" && esp_enc_alg == "3des" && pfs == "yes" -> "true";

The last step, just to be safe, is to implement a pf policy on the laptop to only allow ESP and ISAKMP from the Netscreen gateway. Here is a quick pf.conf file:

# # quick config file to allow IPsec from one IP addr to us # nsip = "24.0.73.58/32" myip = "24.0.73.59/32" intr = "fxp0" # allow ipsec esp and isakmp in/out from the netscreen pass out quick on $intr proto esp from $myip to $nsip pass in quick on $intr proto esp from $nsip to $myip pass out quick on $intr proto udp from $myip to $nsip port = 500 pass in quick on $intr proto udp from $nsip to $myip port = 500 pass out quick on $intr inet proto icmp from $myip to $nsip icmp-type 0 # allow all traffic out from the laptop to the internet pass out quick on $intr inet proto icmp all icmp-type 8 code 0 keep state pass out quick on $intr proto udp from $myip to any keep state pass out quick on $intr proto tcp from $myip to any keep state # block and log all others block in log quick on $intr all block out log quick on $intr all

If you are paying attention, you will notice that we allow ICMP out from the laptop to the outside IP of the netscreen. The reason is that the netscreen might send icmp echo_request as a heartbeat mechanism. However, it is inside the tunnel so we need allow icmp echo reply out (not in the tunnel) since we don't consider the outside IP of the netscreen as part of the tunnel. This is controlled on the netscreen for each IKE gateway with the `heartbeat` parameter unset ike gateway {name} heartbeat hello (this is also called "monitor" in the web GUI).

Author

Brett Eldridge is a technical security consultant. He can be reached at brett@atomicgears.com.

Brett would like to thank those that took the time to review this paper and provide feedback, including: Kevin Steves and Shane Amante.

BRETT ELDRIDGE DOES NOT WARRANT THE ACCURACY OR COMPLETENESS OF THE INFORMATION GIVEN HERE. ANY USE MADE OF, OR RELIANCE ON, SUCH INFORMATION IS ENTIRELY AT USER'S OWN RISK.

$Id: obsd_ns_vpn.html,v 1.14 2002/07/06 20:30:16 stevesk Exp $