Trying to replicate a working IPSec/L2TP config from OpenSWAN to StrongSWAN

Question

I have a working OpenSWAN implementation for RA, using IPsec transport and l2tp for the tunnel, running in AWS. The instance has a private IP, with a public EIP mapped to it.

I use the private ip for the left and leftsubnet parameters and the public in the leftid.

I am now trying to configure an IPSec connection from the same client to a new endpoint, which is running StrongSWAN (4.5.2). I have tried to replicate the config from openswan to strongswan as much as possible. For now, I am only trying to get the IPSec set up (not worrying about l2tp just yet), and am having trouble with phase 2 (phase 1 is completing ok).

The differences in config are:

--- openswan.conf       2014-07-18 11:48:01.740966015 +0200
+++ strongswan.conf     2014-07-18 11:46:58.927569703 +0200
@@ -1,11 +1,14 @@
+version 2.0
+
config setup
-       protostack=netkey
+       charonstart=no
+       interfaces="%none"
        nat_traversal=yes
-       virtual_private=%v4:192.168.10.0/24
        oe=off
-       nhelpers=0
-       interfaces=%defaultroute
+       virtual_private="%v4:192.168.11.0/24"
+
+conn %default
+       keyexchange=ikev1

conn remote-access
        forceencaps=yes
        type=transport
        ike=3des-sha1
-       phase2alg=3des-sha1

When I bring up the connection from my client, I get the following:

003 "myconn" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
108 "myconn" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "myconn" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}
117 "myconn" #2: STATE_QUICK_I1: initiate

And in the server logs

"remote-access"[3] 105.1.1.1 #2: NAT-Traversal: Result using RFC 3947: both are NATed
"remote-access"[3] 105.1.1.1 #2: Peer ID is ID_IPV4_ADDR: '192.168.2.2'
"remote-access"[4] 105.1.1.1 #2: deleting connection "remote-access" instance with peer client.ip.addr {isakmp=#0/ipsec=#0}
"remote-access"[4] 105.1.1.1:4500 #2: sent MR3, ISAKMP SA established
"remote-access"[4] 105.1.1.1:4500 #2: cannot respond to IPsec SA request because no connection is known for 54.1.1.1/32===10.0.0.2:4500[54.1.1.1]:17/1701...105.1.1.1.1:4500[192.168.2.2]:17/%any==={192.168.2.2/32}
"remote-access"[4] 105.1.1.1:4500 #2: sending encrypted notification INVALID_ID_INFORMATION to 105.1.1.1:4500

192.168.2.2 is the private IP of the client and 105.1.1.1 is the public IP that it gets NAT'd to.

I have searched around for "cannot respond to IPsec SA request because no connection is known for" and only come up with 1 relating to strongswan at https://lists.strongswan.org/pipermail/users/2011-July/001885.html, as well as this but neither of the suggestions work (adjusting rightid on the peer or adding leftsourceip on the strongswan server).

The peer / client that I am connecting to strongswan with is libreswan 3.7

edit here's the configs

StrongSWAN in EC:

conn remote-access authby=secret pfs=no left=10.0.0.2 leftid=54..1.1.1 leftsubnet=10.0.0.2/32 leftnexthop=%defaultroute leftprotoport=17/1701 right=%any rightid=%any rightsubnetwithin=0.0.0.0/0 rightprotoport=17/%any type=transport forceencaps=yes auto=add ike=3des-sha1 dpddelay=15 dpdtimeout=45 dpdaction=clear auth=esp esp=aes256-sha1,3des-sha1!

The secrets file on this host:

54.1.1.1 %any : PSK "XXX"

My local RA client config:

conn myconn authby=secret pfs=no rekey=yes keyingtries=3 type=transport left=%defaultroute leftprotoport=17/1701 right=54.1.1.1 rightprotoport=17/1701 auto=add phase2=esp phase2alg=3des-md5;modp1024 forceencaps=yes

secrets:

0.0.0.0 %any 54.1.1.1 : PSK "XXX"

I recently added the phase2 parameters and forceencaps on my local client.

The diffs shown earlier were between 2 EC2-based hosts that I am connecting to. The "myconn" connection is from my workstation, and I have 2 conns, 1 for the openswan peer (which works) and a copy of it for the strongswan peer (which doesn't). I figured using the same approach for left / right configurations would result in a working config.

Answer 1

Here's a working config using openswan. Some of the parameters that had an impact on getting this config working were using rightsubnetwithin and phase2alg (phase2alg can be adjusted as needed, I initially used 3des-sha1, but adjusted later).

example configs

/etc/ipsec.conf

config setup
    plutostderrlog= "/var/log/pluto.err"
    protostack=netkey
    nat_traversal=yes
    virtual_private=%v4:192.168.10.0/24
    oe=off
    nhelpers=0
    interfaces=%defaultroute

conn remote-access
    auto=add
    left=10.0.0.2
    leftid=54.1.1.1
    leftsubnet=10.0.0.2/32
    leftnexthop=%defaultroute
    leftprotoport=17/1701
    rightprotoport=17/%any
    right=%any
    rightid=%any
    rightsubnetwithin=0.0.0.0/0
    forceencaps=yes
    authby=secret
    pfs=no
    type=transport
    auth=esp
    ike=3des-sha1
    phase2alg=3des-sha1
    dpdaction=clear
    dpddelay=60
    dpdtimeout=500

/etc/ipsec.secrets

54.1.1.1 %any : PSK "Your_PSK"

That got the IPSec transport up.

Answer 2

If I understand correctly, one or both endpoints here have RFC1918 addresses, which are behind NAT devices.

You can read more details in an earlier answer of mine, but the upshot is that it breaks the symmetry of the conf file. Instead of each side having the same left= and right= endpoints, and letting SWAN sort out which is which, each side must have its own private ip address, and the other side's public one. It still doesn't matter which is left and which is right on any given end, but the two addresses will be different from the two on the other.

You haven't posted your actual .conf file, only the diffs, so I can't comment further, but I very strongly suspect that this is the problem.