尝试从OpenSWAN复制IPSec/L2TP配置到StrongSWAN

Question

我有一个适用于RA的OpenSWAN实现，在AWS中使用IPsec传输和隧道l2tp。该实例具有一个私有IP，并将一个公共EIP映射到它。

我对left和leftsubnet参数以及leftid中的公共参数使用私有ip。

现在，我正在尝试从同一个客户端配置一个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是它获得NAT的公共IP。

我搜索了“无法响应IPsec SA请求，因为没有已知的连接”，只想出了一个与https://lists.strongswan.org/pipermail/users/2011-July/001885.html的strongswan以及这有关的建议，但这两个建议都不起作用(在对等服务器上调整右侧或在strongswan服务器上添加左源)。

我与强天鹅连接的对等/客户端是libreswan 3.7。

编辑，这是吐露

欧共体的StrongSWAN：

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"

我的本地RA客户端配置：

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参数和强制包。

前面显示的差异是两个基于EC2的主机之间的区别，我正在连接它们。"myconn“连接来自我的工作站，我有2个conns，一个用于openswan对等点(它可以工作)，另一个副本用于强天鹅对等点(它不工作)。我认为，对左/右配置使用相同的方法会产生工作配置。

Answer 1

下面是一个使用openswan的工作配置。影响此配置工作的一些参数是使用rightsubnetwithin和phase2alg (phase2alg可以根据需要进行调整，我最初使用的是3DE-SHA 1，但后来进行了调整)。

示例信任

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

这让IPSec的传输系统启动了。

Answer 2

如果我正确理解，这里的一个或两个端点都有RFC1918地址，这些地址位于NAT设备后面。

您可以在我早些时候的回答中阅读更多细节，但结果是它破坏了conf文件的对称性。而不是每一方都有相同的left=和right=端点，让SWAN找出哪一方是哪一方，每一方必须有自己的私有ip地址，而另一方的公共地址。不管哪个是left，哪个是给定端的right，但是这两个地址将与另两个地址不同。

您还没有发布您的实际.conf文件，只有差异，所以我不能进一步评论，但我非常强烈地怀疑这是问题所在。