При попытке копировать работу IPSec/L2TP конфигурируются от OpenSWAN до StrongSWAN

У меня есть рабочая реализация OpenSWAN для РА, с помощью транспорта IPsec и l2tp для туннеля, работая в AWS. Экземпляр имеет частный IP с общедоступным EIP, отображенным на нем.

Я использую частный IP для left и leftsubnet параметры и общественность в leftid.

Я теперь пытаюсь настроить соединение IPsec от того же клиента к новой конечной точке, которая выполняет StrongSWAN (4.5.2). Я попытался копировать конфигурацию от openswan до strongswan как можно больше. На данный момент я только пытаюсь разбудить набор IPSec (просто еще не вызывающий беспокойство о l2tp) и испытываю затруднения из-за фазы 2 (фаза 1 завершается хорошо).

Различия в конфигурации:

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

Когда я поднимаю соединение от своего клиента, я получаю следующее:

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

И в журналах сервера

"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 частный IP клиента, и 105.1.1.1 общедоступный IP, к которому это получает NAT'd.

Я искал вокруг, "не может ответить на запрос IPsec SA, потому что никакое соединение не известно" и только придумано 1 касающийся strongswan в https://lists.strongswan.org/pipermail/users/2011-July/001885.html, а также этом, но ни одной из работы предложений (корректирующийся исправленный на одноранговом узле или добавляющий leftsourceip на strongswan сервере).

Одноранговый узел / клиент, с которым я соединяюсь с strongswan, является libreswan 3.7

редактирование здесь является конфигурациями

StrongSWAN в 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!

Секретный файл на этом хосте:

54.1.1.1 %any : PSK "XXX"

Моя локальная клиентская конфигурация РА:

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

секреты:

0.0.0.0 %any 54.1.1.1 : PSK "XXX"

Я недавно добавил phase2 параметры и forceencaps на моем локальном клиенте.

diffs, показанные ранее, были между 2 основанными на EC2 хостами, с которыми я соединяюсь. "myconn" соединение от моей рабочей станции, и я имею 2, ведет, 1 для однорангового узла openswan (который работает), и копия его для однорангового узла strongswan (который не делает). Я изобразил использование того же подхода для левого / правильные конфигурации приведут к рабочей конфигурации.