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"
-       virtual_private=%v4:
-       nhelpers=0
-       interfaces=%defaultroute
+       virtual_private="%v4:"
+conn %default
+       keyexchange=ikev1

conn remote-access
-       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] #2: NAT-Traversal: Result using RFC 3947: both are NATed
"remote-access"[3] #2: Peer ID is ID_IPV4_ADDR: ''
"remote-access"[4] #2: deleting connection "remote-access" instance with peer client.ip.addr {isakmp=#0/ipsec=#0}
"remote-access"[4] #2: sent MR3, ISAKMP SA established
"remote-access"[4] #2: cannot respond to IPsec SA request because no connection is known for[]:17/1701...[]:17/%any==={}
"remote-access"[4] #2: sending encrypted notification INVALID_ID_INFORMATION to is the private IP of the client and 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= leftid=54..1.1.1 leftsubnet= leftnexthop=%defaultroute leftprotoport=17/1701 right=%any rightid=%any rightsubnetwithin= 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: %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= rightprotoport=17/1701 auto=add phase2=esp phase2alg=3des-md5;modp1024 forceencaps=yes

secrets: %any : 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.

2 Answers 2


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


config setup
    plutostderrlog= "/var/log/pluto.err"

conn remote-access

/etc/ipsec.secrets %any : PSK "Your_PSK"

That got the IPSec transport up.


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.

  • Thanks for the response, I have added the update. I have added the config to see if there is anything obvious I am overlooking. This is not a site to site connection, but rather a client to site connection.
    – Brett
    Jul 18, 2014 at 11:08
  • From SWAN's point of view, there is no difference between those two types of connection; one just routes a /32 which is its own address. Thanks for the update; does left really own the IP address (ie, does it have on one of its own interfaces the real address that you have redacted as
    – MadHatter
    Jul 18, 2014 at 11:11
  • is an EIP, no it's not on the left. left has 1 interface (eth0) which has on it and AWS handles the NAT for to That's why I am using it for leftid only and not left. I can remove the leftid param from the left side and add rightid= to the right side and that also works to get past phase 1. However, I end up with the same rror when i start phase 2.
    – Brett
    Jul 18, 2014 at 11:22
  • 1
    Without leftid on the left or rightid on the right, I get an error: we require peer to have ID '', but peer declares ''
    – Brett
    Jul 18, 2014 at 11:28
  • What about with just leftid= on the right, and rightid= on the left, each specifying the private IP address of the other?
    – MadHatter
    Jul 18, 2014 at 13:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .