StrongSwan

From royhills
Jump to: navigation, search

Platform Notes

strongSwan 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.

All versions support standard IKE (IKEv1) using the pluto IKE deamon. Recent versions (from version 4.0.0) also support IKEv2 using the charon daemon.

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

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

Version History

There are currently two strongSwan branches: the stable 2.x branch, and the development 4.x branch.

The first strongSwan version was 2.0.0, dated March 2004, which was based on FreeS/WAN 2.04 plus X.509, NAT Traversal and AES encryption patches.

strongSwan 4.0.0, dated May 2006, was based on strongSwan 2.7.0.

In addition to the releases on each branch, the latest code is also available via CVS.

Backoff Pattern

IKEv1 with pluto

With IKEv1 using the pluto daemon, strongSwan has the backoff pattern 

0, 10, 20

This pattern is also shared by FreeS/WAN and OpenSwan because all of these are based on the FreeS/WAN pluto daemon.

Below is an example from strongSwan 4.0.5 running on Debian Linux: 

$ 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=a997321d37e9afa2)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

IKE Backoff Patterns:

IP Address      No.     Recv time               Delta Time
172.16.3.18     1       1171468498.860140       0.000000
172.16.3.18     2       1171468508.869134       10.008994
172.16.3.18     3       1171468528.888169       20.019035
172.16.3.18     Implementation guess: Linux FreeS/WAN, OpenSwan, strongSwan

IKEv2 with Charon

With IKEv2, using the charon daemon, strongSwan does not do any re-transmission. Below is an example from strongSwan 4.0.5 on Debian Linux. Note that there is only a single packet in the pattern, indicating no retransmission is being performed by the strongSwan server. 

$ ike-scan --ikev2 -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     IKEv2 SA_INIT Handshake returned
        HDR=(CKY-R=543caf8e5aa2f2fd, IKEv2)
        SA=(Encr=AES_CBC,KeyLength=128 Integ=HMAC_SHA1_96 Prf=HMAC_SHA1 DH_Group=14:modp2048)
        KeyExchange(132 bytes)
        Nonce(16 bytes)

IKE Backoff Patterns:

IP Address      No.     Recv time               Delta Time
172.16.3.18     1       1171468775.120626       0.000000
172.16.3.18     Implementation guess: Linksys Etherfast

Vendor IDs

strongSwan 4.x returns two Vendor IDs in the first responder packet under IKE Main Mode:

  • strongSwan VID (MD5 Hash of "strongSwan 4.x.y", where x.y is the minor version number)
  • Dead Peer Detection VID (afcad71368a1f1c96b8696fc77570100)

Because the strongSwan VID is a hash of the version number, it can be used to identify the exact version of strongSwan.

The example below shows the Vendor IDs returned by strongSwan 4.0.5 on Debian Linux: 

$ 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=376ab8a5bb2f443d)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Authentication Methods

strongSwan 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.

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. 

conn iketest
        left=172.16.3.18
        leftsubnet=172.16.3.0/24
        right=%any
        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=d0cc0abad9d372fe)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        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=2fe7d819d2601f44)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

ISAKMP SA Lifetime

Lifetime in seconds

strongSwan 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: 

$ ike-scan -M --lifetime=none --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     Main Mode Handshake returned
        HDR=(CKY-R=5a3610d1cdff1dea)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

$ ike-scan -M --lifetime=1 --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     Main Mode Handshake returned
        HDR=(CKY-R=6e7acddc8cdf90ef)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00000001)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

$ ike-scan -M --lifetime=86400 --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     Main Mode Handshake returned
        HDR=(CKY-R=4f65b272c6f96be8)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00015180)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

$ ike-scan -M --lifetime=86401 --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=43bbf79744a6b00b)

strongSwan accepts a variable-length lifetime sttribute with a seemingly arbitary 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,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     Main Mode Handshake returned
        HDR=(CKY-R=1c6eb126df6bff64)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds
            LifeDuration(32)=0x0000000000000000000000000000000000000000000000000000000000000001)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Lifetime in Kilobytes

strongSwan 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,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     Main Mode Handshake returned
        HDR=(CKY-R=fe75d62f5cbc9c7a)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Kilobytes LifeDuration(4)=0x00000000)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

A lifetime of 1 kilobyte. 

$ ike-scan -M --lifetime=none --lifesize=1 --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     Main Mode Handshake returned
        HDR=(CKY-R=2aea9f0807ce816d)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Kilobytes LifeDuration(4)=0x00000001)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        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,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     Main Mode Handshake returned
        HDR=(CKY-R=d76d428d5e5e56e8)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Kilobytes LifeDuration(8)=0xffffffffffffffff)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        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,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     Main Mode Handshake returned
        HDR=(CKY-R=c4a08a38583a9f3b)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00015180 LifeType=Kilobytes LifeDuration(4)=0xffffffff)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

Transform ordering and rewriting

strongSwan 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 the target returns the attributes in the same order as the initiator specified them. 

$ ike-scan -M --trans="(1=5,2=2,3=3,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=9d2b3e904a3ab3e1)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

$ ike-scan -M --trans="(4=2,3=3,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=d9f5aec66242df7e)
        SA=(Group=2:modp1024 Auth=RSA_Sig Hash=SHA1 Enc=3DES)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        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=3,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=c53786f9985fea68)
        SA=(LifeType=Kilobytes LifeDuration=123 LifeType=Seconds LifeDuration=456 Group=2:modp1024 Auth=RSA_Sig Hash=SHA1 Enc=3DES)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

strongSwan 4.0.5 (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=3,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=dcf1c29da6a493c5)
        SA=(Group=2:modp1024 Auth=RSA_Sig Hash=SHA1 Enc=AES KeyLength=128)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)

$ ike-scan -M --trans="(4=2,3=3,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=7e2ea4c1f76657c8)

Aggressive Mode

strongSwan does not support IKE Aggressive Mode. If you try to use aggressive mode, it replies with an informational exchange containing notify message 29 (UNSUPPORTED-EXCHANGE-TYPE) as illustrated below: 

$ ike-scan -A -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     Notify message 29 (UNSUPPORTED-EXCHANGE-TYPE)
        HDR=(CKY-R=0000000000000000)

This means that remote access connections where the initiator's IP address is not static cannot use pre-shared key authentication, and must use certificates instead. This is because Main Mode cannot be used with Pre-Shared key authentication when the initiator's IP address is not known in advance.

Response to non-compliant and malformed packets

In all the examples below, we specify a single transform. Except in the case where we are deliberately specifying an unacceptable transform, the attributes are Enc=3DES, Hash=SHA1, Auth=RSA_Sig, Group=2, which is acceptable to the target system.

Except in the unacceptable transform case, the responder cookie is always zero when reporting an error. This is similar to CheckPoint Firewall-1, except that CheckPoint responds with a zero cookie in all cases.

In general, strongSwan responds to invalid packets by sending a notify message, and it uses the notification message that would be expected.

No Acceptable Transforms

strongSwan will return notify message 14 (NO-PROPOSAL-CHOSEN) if the Encryption Algorithm, Hash Algorithm, or Diffie-Hellman group is unsupported. However it will not respond at all for an unsupported Authentication Method.

The example below shows the response to a single transform where the encryption algorithm is set to DES, which is not supported. All other attributes are supported. 

$ ike-scan -M --trans=1,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=cf677d98bff73747)

Bad IKE version

$ ike-scan -M --headerver=0x30 --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 5 (INVALID-MAJOR-VERSION)
        HDR=(CKY-R=0000000000000000)

$ ike-scan -M --headerver=0x11 --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 6 (INVALID-MINOR-VERSION)
        HDR=(CKY-R=0000000000000000)

Invalid DOI

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

$ ike-scan -M --doi=2 --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 16 (PAYLOAD-MALFORMED)
        HDR=(CKY-R=0000000000000000)

Invalid Situation

$ ike-scan -M --situation=2 --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 3 (SITUATION-NOT-SUPPORTED)
        HDR=(CKY-R=0000000000000000)

Invalid Initiator Cookie

$ ike-scan -M --cookie=0000000000000000 --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 4 (INVALID-COOKIE)
        HDR=(CKY-R=0000000000000000)

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 --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 16 (PAYLOAD-MALFORMED)
        HDR=(CKY-R=0000000000000000)

Invalid Protocol

$ ike-scan -M --protocol=2 --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 10 (INVALID-PROTOCOL-ID)
        HDR=(CKY-R=0000000000000000)

Invalid SPI

$ ike-scan -M --spisize=32 --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 11 (INVALID-SPI)
        HDR=(CKY-R=0000000000000000)

Non-Zero Reserved Fields

$ ike-scan -M --mbz=255 --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 16 (PAYLOAD-MALFORMED)
        HDR=(CKY-R=0000000000000000)

Nat Traversal

strongSwan 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 strongSwan will not respond to NAT Traversal encapsulated packets.

Here is an example of a NAT Traversal response. 

$ ike-scan -M --nat-t --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     Main Mode Handshake returned
        HDR=(CKY-R=f784c6ecc962e297)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        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 --trans=5,2,3,2 --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=94f22001c70308c6)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
        VID=4a131c81070358455c5728f20e95452f (RFC 3947 NAT-T)

IKEv2

strongSwan version 4.x supports both IKE and IKEv2. Here is an example IKEv2 response from a strongSwan 4.0.5 system running on Debian Linux: 

$ ike-scan -M --ikev2 172.16.3.18
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.3.18     IKEv2 SA_INIT Handshake returned
        HDR=(CKY-R=35eafcd831ba1227, IKEv2)
        SA=(Encr=AES_CBC,KeyLength=128 Integ=HMAC_SHA1_96 Prf=HMAC_SHA1 DH_Group=14:modp2048)
        KeyExchange(132 bytes)
        Nonce(16 bytes)

The configuration entry from ipsec.conf on this system is: 

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

Remote Access VPN Client

strongSwan 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 most notify messages

When a strongSwan system responds with an informational exchange containing a notify message, indicating an error condition, it sets the responder cookie to zero unless the notify message is NO-PROPOSAL-CHOSEN.

This is similar to CheckPoint Firewall-1, but with CheckPoint the responder cookie is zero for all notify messages.

Default Configuration

By default, strongSwan 4.0.5 supports the following transform attribute values:

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

This is a very impressive set of supported attribute values.

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, and also the new SHA2-256 and SHA2-512 hash algorithms.

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

Blowfish, Serpent and Twofish are very unusual.

Serpent and Twofish use the values 65004 and 65005 respectively, which are outside the IETF allocated range for encryption algorithm values. It is not known if this will interoperate with other vendors because I've not observed any other product that offers Serpent or Twofish.

It is possible to restrict the attributes that strongSwan will accept with the ike configuration entry. E.g. ike=3des-md5! would only allow 3DES encryption with MD5 hash. The exclamation mark at the end of the cipher list specifies that only this list is acceptable.

Discovered Vulnerabilities

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