Difference between revisions of "OpenSwan"

From royhills
Jump to: navigation, search
m (Reverted edits by RacchIroln (Talk) to last version by Royhills)
 
(No difference)

Latest revision as of 08:33, 20 July 2009

Platform Notes

OpenSwan is an open source IPsec VPN solution that runs on Linux systems with either 2.4 or 2.6 kernels. The data encryption is handled by the Linux kernel (using KLIPS for 2.4, or Linux native IPsec for 2.6), and IKE is handled with a user mode process called pluto.

OpenSwan was originally based on the FreeS/WAN product, which is no longer being maintained. Here are the IKE details for FreeS/WAN.

strongSwan is a similar open source Linux IPsec VPN product, which was also based on FreeS/WAN. Here are the IKE details for StrongSwan.

Version History

There are three major release branches of OpenSwan:

  • OpenSwan 1.x - based off the last version of Super FreeS/WAN (1.99.8.2) with few additional features, and only bugfixes applied. It works for the Linux Kernel 2.0, 2.2 and 2.4 series (but not 2.6). The OpenSwan 1.x branch is now considered obsolete.
  • OpenSwan 2.x - This is the current stable branch. It supports Linux 2.4 (KLIPS) or 2.6 (Native). Versions 2.6.x and up support IKEv2
  • OpenSwan 3.x - This is an experimental release, which adds new features (crypto hardware offloading) and supports FreeBSD, NetBSD and OSX in addition to Linux.

Backoff Pattern

OpenSwan has the IKE backoff pattern: 

0, 10, 20

This is the same backoff pattern as strongSwan, which is not surprising as they are both based on FreeS/WAN. The backoff pattern is the same in both Main Mode and Aggressive Mode. Here is an example backoff pattern from OpenSwan 2.4.6 running on Debian Etch: 

$ ike-scan -M --showbackoff 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=53f1091218983455)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

IKE Backoff Patterns:

IP Address      No.     Recv time               Delta Time
172.16.3.18     1       1172414891.734288       0.000000
172.16.3.18     2       1172414901.727185       9.992897
172.16.3.18     3       1172414921.716877       19.989692
172.16.3.18     Implementation guess: Linux FreeS/WAN, OpenSwan, strongSwan

Vendor IDs

OpenSwan v2 returns two Vendor IDs:

  • The OpenSwan Vendor ID (described below);
  • Dead Peer Detection v1.0 (afcad71368a1f1c96b8696fc77570100)

The OpenSwan Vendor ID is a 12-byte printable string that consists of the string "OE" (hex 4f45) followed by 10 bytes (20 hex characters) of data that depends on the OpenSwan version and compile-time options. This ten bytes of data is a truncated "ASCIIfied" MD5 hash of the OpenSwan version string. The "ASCIIfication" process consists of clearing bit 7 and setting bit 6 in each byte, thus constraining the range to 64-127 inclusive.

The OpenSwan version string can be obtained by running pluto with the --version option, as shown below: 

$ /usr/lib/ipsec/pluto --version
Openswan 2.4.6 X.509-1.5.4 LDAP_V3 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR
Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005
    Henry Spencer, Richard Guy Briggs, Sam Sgro
    D. Hugh Redelmeier, Sandy Harris, Claudia Schmeing,
    Michael C. Richardson, Angelos D. Keromytis, John Ioannidis.
    Ken Bantoft, Andreas Steffen, Mathieu Lafon, Tuomo Soini
    Paul Wouters

This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
Public License (file COPYING in the distribution) for more details.

In this example, the version string is Openswan 2.4.6 X.509-1.5.4 LDAP_V3 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR.

The following perl script can be used to convert an OpenSwan pluto version string to its corresponding Vendor ID: 

#!/usr/bin/perl
use warnings;
use strict;
use Digest::MD5 qw(md5);
#
my $openssl_version = shift();
die "Usage: openswan-vid <OpenSwan_version_string>\n" unless defined $openssl_version;
#
my $md5_hash = md5($openssl_version);
my @values = unpack("C10", $md5_hash);
my $value;
#
print "4f45";   # Hex representation of "OE"
foreach (@values) {
   $value = $_ & 0x7f | 0x40;   # Set bit-7 and clear bit-6
   printf("%x", $value);
}
print "\n";

Running this with the version string that we obtained previously gives: 

$ openswan-vid "Openswan 2.4.6 X.509-1.5.4 LDAP_V3 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR"
4f456c4c4f5d5264574e5244

On startup, pluto sends a message to syslog detailing its version string and Vendor ID (in ASCII). Here is an example syslog message: 

Starting Pluto (Openswan Version 2.4.6 X.509-1.5.4 LDAP_V3 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OElLO]RdWNRD)

The OpenSwan Vendor ID is only returned in Main Mode, not in Aggressive Mode.

Authentication Methods

OpenSwan supports Pre-Shared Key and RSA Signature authentication methods. The method to use is defined by the authby configuration option, which can take values of secret for Pre-Shared Key or rsasig for RSA Signature. If no authby option is specified, the default authentication method is RSA Signature.

RSA Signature Example

In this example, we don't specify an authentication method in ipsec.conf so the default of RSA Signature is used. We need to use the --auth=3 option to ike-scan to specify RSA Signature authentication.

Note that unlike strongSwan 4.x.y, we cannot use %any as the remote peer address. If we do, pluto gives the error fatal error in "iketest": ID "%any" cannot have RSA key. So we specify the testing system's IP address instead. 

conn iketest
        left=172.16.3.18
        leftsubnet=172.16.3.0/24
        right=192.168.124.3
        auto=add

$ ike-scan -M --auth=3 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=129e1887612e583a)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Pre-Shared Key Example

In this example, we specify Pre-Shared Key authentication in ipsec.conf with authby=secret. 

conn iketest
        left=172.16.3.18
        leftsubnet=172.16.3.0/24
        right=%any
        authby=secret
        auto=add

$ ike-scan -M 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=ddd3ded9958632c1)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

ISAKMP SA Lifetime

Lifetime in seconds

OpenSwan accepts either no SA lifetime in seconds (i.e. the attribute is not present), or a value in the range 0 to 86,400 seconds (24 hours) inclusive. Values outside this range result in a NO-PROPOSAL-CHOSEN message. The examples below illustrate this behaviour:

No lifetime at all. 

$ ike-scan -M --lifetime=none --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=9a0b8b746f18e979)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

A lifetime of zero seconds. 

$ ike-scan -M --lifetime=0 --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=40a5b1e660d961b4)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00000000)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

A lifetime of one second. 

$ ike-scan -M --lifetime=1 --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=37b291540dc3e917)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00000001)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

A lifetime of 86,400 seconds. This is the largest value that OpenSwan will accept. 

$ ike-scan -M --lifetime=86400 --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=57e78f74228d7479)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00015180)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

A lifetime of 86,401 seconds, which OpenSwan rejects. 

$ ike-scan -M --lifetime=86401 --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=4f1ae85a7c09057e)

OpenSwan accepts a variable-length lifetime attribute with a seemingly arbitrary value length, providing the value is within the acceptable range. This has been tested up to value lengths of 256 bytes. The example below shows the response to a lifetime in seconds value of 1 encoded as a variable length attribute with 32 bytes. The lines have been wrapped to aid readability: 

$ ike-scan -M --lifetime=0x0000000000000000000000000000000000000000000000000000000000000001
  --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=4a047fcf0a1da9f2)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds
            LifeDuration(32)=0x0000000000000000000000000000000000000000000000000000000000000001)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Lifetime in Kilobytes

OpenSwan supports any SA lifetime in Kilobytes, including none at all. There appears to be no upper limit to the SA lifetime. It also supports both lifetime in seconds and lifetime in kilobytes together. The examples below illustrate the behaviour:

No lifetime in seconds, zero lifetime in kilobytes. 

$ ike-scan -M --lifetime=none --lifesize=0 --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=1ad387cf85c69add)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Kilobytes LifeDuration(4)=0x00000000)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

A lifetime of 1 kilobyte. 

$ ike-scan -M --lifetime=none --lifesize=1 --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=3e91efa1a0c5c653)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Kilobytes LifeDuration(4)=0x00000001)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

A huge lifetime in kilobytes. 0xffffffffffffffff is about 1.8x10^19. 

$ ike-scan -M --lifetime=none --lifesize=0xffffffffffffffff --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=31783ef1b5e528ca)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Kilobytes LifeDuration(8)=0xffffffffffffffff)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

A huge lifetime in kilobytes with the maximum permitted lifetime in seconds. 

$ ike-scan -M --lifetime=86400 --lifesize=0xffffffff --trans=5,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=501c7aa9f6086d8a)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00015180 LifeType=Kilobytes LifeDuration(4)=0xffffffff)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Transform ordering and rewriting

OpenSwan generally returns the transform attributes in the order that they are supplied by the initiator.

In the example below, we specify the four mandatory transform attributes in order Enc, Hash, Auth, Group and then in reverse order Group, Auth, Hash, Enc, and observe that in both cases the target returns the attributes in the same order as the initiator specified them. 

$ ike-scan -M --trans="(1=5,2=2,3=1,4=2)" 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=dff0c1d3f36f4aa3)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

$ ike-scan -M --trans="(4=2,3=1,2=2,1=5)" 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=9f67aa4386d00ca2)
        SA=(Group=2:modp1024 Auth=PSK Hash=SHA1 Enc=3DES)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Here is another example, this time including a lifetime in seconds, and a lifetime in kilobytes. Again, the attributes are returned in the same order that the initiator sent them. 

$ ike-scan -M --trans="(11=2,12=123,11=1,12=456,4=2,3=1,2=2,1=5)" 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=801c5fe8bb105f0a)
        SA=(LifeType=Kilobytes LifeDuration=123 LifeType=Seconds LifeDuration=456 Group=2:modp1024 Auth=PSK Hash=SHA1 Enc=3DES)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

OpenSwan 2.4.6 (and maybe other versions as well) requires that the keylength attribute follows the encryption algorithm attribute when variable length ciphers are used. Below is an example using AES-128. In the first example the attribute ordering is DH Group, Auth, Hash, Enc, Keylen, which works, while in the second it is DH Group, Auth, Hash, Keylen, Enc which doesn't work and returns NO-PROPOSAL-CHOSEN. 

$ ike-scan -M --trans="(4=2,3=1,2=2,1=7,14=128)" 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=90d80560d8f9e3eb)
        SA=(Group=2:modp1024 Auth=PSK Hash=SHA1 Enc=AES KeyLength=128)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

$ ike-scan -M --trans="(4=2,3=1,2=2,14=128,1=7)" 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=27b7b38c2c460b9c)

Aggressive Mode

OpenSwan supports aggressive mode, but it needs to be enabled with the config file option aggrmode=yes. It also appears to be necessary to specify the IKE Phase-1 transform attributes with the ike config option. Finally, there needs to be an entry in the ipsec.secrets file which matches the ID that is specified by the initiator.

In the example below, we use the following connection specification in ipsec.conf: 

conn iketest
        left=172.16.3.18
        leftsubnet=172.16.3.0/24
        right=%any
        authby=secret
        ike=3des-sha-modp1024
        aggrmode=yes
        auto=add

Here is the entry in the ipsec.secrets file using the ID royhills@hotmail.com: 

172.16.3.18 royhills@hotmail.com: PSK "abc123"

This is how it responds to ike-scan with the default transform set and the ID royhills@hotmail.com with the default ID type of ID_USER_FQDN: 

$ ike-scan -M -A --id=royhills@hotmail.com 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Aggressive Mode Handshake returned
        HDR=(CKY-R=43aa47a2540f2cd4)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        KeyExchange(128 bytes)
        Nonce(16 bytes)
        ID(Type=ID_IPV4_ADDR, Value=172.16.3.18)
        Hash(20 bytes)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Note that in aggressive mode, it doesn't include the OpenSwan Vendor ID.

If we specify an ID that doesn't exist, in this case johndoe@hotmail.com, OpenSwan will respond with the notify message NO-PROPOSAL-CHOSEN: 

$ ike-scan -A -M --id=johndoe@hotmail.com 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=55c0ae38c314fade)

Response to non-compliant and malformed packets

No Acceptable Transforms

OpenSwan will return notify message 14 (NO-PROPOSAL-CHOSEN) if the transform attributes are not supported. It differs from strongSwan in that it will return a notify message for an invalid authentication method, whereas strongSwan (at least version 4.0.5) does not respond at all to a bad authentication method.

Here is an unsupported encryption algorithm (single DES): 

$ ike-scan -M --trans=1,2,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=ed69dc8cf8f58691)

Here is an unsupported hash algorithm (Tiger): 

$ ike-scan -M --trans=5,3,1,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=02f0a4d9a1deb927)

Here is an unsupported authentication method (RSA Signature). This connection is configured to use pre-shared key: 

$ ike-scan -M --trans=5,2,3,2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=cb0cb0abe993d69d)

And here is an unsupported Diffie-Hellman group (group 1 - MODP 768): 

$ ike-scan -M --trans=5,2,1,1 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=8cebca861205a8ef)

Bad IKE version

$ ike-scan -M --headerver=0x30 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 5 (INVALID-MAJOR-VERSION)
        HDR=(CKY-R=0000000000000000)

$ ike-scan -M --headerver=0x11 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 6 (INVALID-MINOR-VERSION)
        HDR=(CKY-R=0000000000000000)

Invalid DOI

Given the other responses, I would have expected OpenSwan to respond with notify message 2 (DOI-NOT-SUPPORTED) rather than message 16 (PAYLOAD-MALFORMED). 

$ ike-scan -M --doi=2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 16 (PAYLOAD-MALFORMED)
        HDR=(CKY-R=0000000000000000)

Invalid Situation

Note that OpenSwan responds with a non-zero responder cookie, whereas strongSwan responds with a zero cookie. 

$ ike-scan -M --situation=2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 3 (SITUATION-NOT-SUPPORTED)
        HDR=(CKY-R=1400e2e8b6bc578a)

Invalid Initiator Cookie

No response. strongSwan responds with Notify message 4 (INVALID-COOKIE) instead. 

$ ike-scan -M --cookie=0000000000000000 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)

Ending ike-scan 1.9: 1 hosts scanned in 2.474 seconds (0.40 hosts/sec).  0 returned handshake; 0 returned notify

Invalid Flags

Given the other responses, I would have expected strongSwan to respond with notify message 8 (INVALID-FLAGS) rather than message 16 (PAYLOAD-MALFORMED). 

$ ike-scan -M --hdrflags=255 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 16 (PAYLOAD-MALFORMED)
        HDR=(CKY-R=0000000000000000)

Invalid Protocol

OpenSwan responds with a non-zero responder cookie, whereas strongSwan responds with a zero cookie. 

$ ike-scan -M --protocol=2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 10 (INVALID-PROTOCOL-ID)
        HDR=(CKY-R=59431a2f95a0f0a7)

Invalid SPI

OpenSwan responds with a non-zero responder cookie, whereas strongSwan responds with a zero cookie. 

$ ike-scan -M --spisize=32 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 11 (INVALID-SPI)
        HDR=(CKY-R=5e3b61f4cbcd2bb4)

Non-Zero Reserved Fields

$ ike-scan -M --mbz=255 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Notify message 16 (PAYLOAD-MALFORMED)
        HDR=(CKY-R=0000000000000000)

Nat Traversal

OpenSwan supports RFC 3947 NAT Traversal, but only if it is enabled with nat_traversal=yes in the config setup section of ipsec.conf. If it is not enabled, then OpenSwan will not respond to NAT Traversal encapsulated packets.

Here is an example of a NAT Traversal response. 

$ ike-scan -M --nat-t 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=524761c7f846eac7)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Here is another example, this time specifying the NAT Traversal Vendor ID, which is then included in the response. 

$ ike-scan -M --nat-t --vendor=4a131c81070358455c5728f20e95452f 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     Main Mode Handshake returned
        HDR=(CKY-R=a0b1a45afaba02ee)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f456c4c4f5d5264574e5244
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
        VID=4a131c81070358455c5728f20e95452f (RFC 3947 NAT-T)

IKEv2

OpenSwan does not support IKEv2 in version 2.4.x. It does support IKEv2 in the 2.6.x series.

Remote Access VPN Client

OpenSwan does not include a remote access VPN client. However, it should work with generic VPN clients such as SafeNet because it does not use any proprietary mechanisms.

Other Interesting Behaviour

Zero responder cookies in some notify messages

When an OpenSwan system responds with an informational exchange containing a notify message, indicating an error condition, it sets the responder cookie to zero for some notify messages, and non-zero for others.

OpenSwan 2.4.6 responds with a zero cookie for the following notify types:

  • 5 (INVALID-MAJOR-VERSION)
  • 6 (INVALID-MINOR-VERSION)
  • 16 (PAYLOAD-MALFORMED)

and it responds with a non-zero cookie for the following types:

  • 3 (SITUATION-NOT-SUPPORTED)
  • 10 (INVALID-PROTOCOL-ID)
  • 11 (INVALID-SPI)
  • 14 (NO-PROPOSAL-CHOSEN)

The only other known implementations to respond with a zero cookie is CheckPoint (which always responds with a zero cookie for notify messages) and strongSwan (which responds with a zero cookie for most notify messages).

AES key length

This applies to OpenSwan 2.4.12.

In the default configuration, or if AES is specified as the Phase-1 encryption algorithm without a key length, OpenSwan allows the initiator to specify no key length for AES, and the responders proposal will contain no keylength either: 

# ike-scan --trans=7,2,3,2 -M 192.168.88.129
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
192.168.88.129  Main Mode Handshake returned
        HDR=(CKY-R=c9914783fa94a6fe)
        SA=(Enc=AES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f45606c50487c5662707575
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Openswan also allows any AES key length between 128 and 256 inclusive. Not just the three defined lengths: 128, 192 and 256. For example, it will respond to a request for 137-bit AES: 

# ike-scan --trans=7/137,2,3,2 -M 192.168.88.129
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
192.168.88.129  Main Mode Handshake returned
        HDR=(CKY-R=ad96513363e5a737)
        SA=(Enc=AES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 KeyLength=137 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4f45606c50487c5662707575
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

When OpenSwan is the initiator, and AES has been specified as the Phase-1 encryption algorithm without a key length, it does not include a keylength attribute in the transform: 

16:23:12.329721 IP 192.168.88.129.500 > 192.168.88.130.500: isakmp 1.0 msgid : phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #0 protoid=isakmp transform=1
            (t: #0 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=aes)
                          (type=hash value=sha1)(type=auth value=rsa sig)(type=group desc value=modp1024))))

Default Configuration

Initiator

By default, OpenSwan 2.4.12 sends the following four transforms when it is acting as the IKE Phase-1 initiator.

No. Encryption Hash Authentication DH Group ISAKMP SA Lifetime
0 3DES MD5 PSK or RSA_Sig 5 3600 Seconds
1 3DES SHA1 PSK or RSA_Sig 5 3600 Seconds
2 3DES SHA1 PSK or RSA_Sig 2 3600 Seconds
3 3DES MD5 PSK or RSA_Sig 2 3600 Seconds

In all cases, the authentication mechanism is set to either PSK or RSA_Sig depending on the authby setting in ipsec.conf.

I don't know why OpenSwan prefers 3DES/MD5 over 3DES/SHA1 with Diffie-Hellman group 5 because MD5 is a weaker hash algorithm. For Diffie Hellman group 2 it prefers 3DES/SHA1 over 3DES/MD5, which is the more logical ordering.

The SA lifetime of 3600 seconds is very low for an ISAKMP SA.

Responder

By default, OpenSwan 2.4.6 supports the following transform attribute values for IKE Phase-1 when it is acting as the responder:

Encryption 3DES, AES-128, AES-192 and AES-256
Hash MD5, SHA1
Authentication RSA Signature (optionally Pre-Shared Key)
DH Group 2, 5, 14, 15, 16, 17 and 18

The algorithms supported for IKE Phase-1 can be displayed on the OpenSwan system with: 

lenny-openswan# ipsec auto --status | grep "algorithm IKE"
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192

As described in the Authentication Methods section above, the default method is RSA Signature, but Pre-Shared key can also be specified.

No weak ciphers are supported by default. In particular there is no support for single DES or Diffie-Hellman group 1.

It is interesting to see support for the newer MODP Diffie-Hellman groups 14 to 18 from RFC 3526.

It's unusual to see support for AES-192. Most implementations restrict themselves to AES keylengths of 128 or 256.

It is possible to restrict the attributes that OpenSwan will accept with the ike configuration entry. By specifying an ike= line, these attributes become the only valid proposals. eg ike=3des-sha1,aes-md5 means that only those two proposals will be allowed. It would not allow 3des-md5 or aes-sha1. Old versions of openswan used a "!" operator to signify the options should be interpreted as 'restricted'.

Discovered Vulnerabilities

Retrieved from ‘http://www.royhills.co.uk/wiki/index.php?title=OpenSwan&oldid=2903’