[strongSwan] cannot respond to IPsec SA request because no connection is known

[Ben Beuchler]

I'm trying to connect from behind a standard PAT style NAT to a
StrongSwan server behind a 1:1 NAT.  The config I'm using worked when
I was connecting between two hosts on the local subnet.  When I
deployed the new VPN server behind the firewall at our datacenter, it
would no longer work (errors included below).  Any idea what I'm doing
wrong?

Here's how the network is configured:

Client (192.168.22.94) -> Office Firewall (Linux NAT, external: 209.240.75.80)
...
Internet
...
Datacenter Firewall (pfSense, 1:1 NAT 209.240.75.7 -> 10.1.0.7) -> VPN
server (10.1.0.7)

If I run tcpdump on both the server and the client while attempting to
establish a session, it appears every packet sent from one side
arrives on the other, so I'm reasonably confident the network side is
working.  Also normal TCP connections directly to the 1:1 NAT IP work
just fine.

The client is the native IPsec/L2TP client on OS X 10.7.4, same client
as the initial tests without NAT.  The server in both cases was
strongswan 4.3.2 on Ubuntu 10.04.

ipsec.conf on server:

config setup
    nat_traversal=yes
    charonstart=no
    plutostart=yes

conn L2TP
    authby=psk
    pfs=no
    rekey=no
    type=tunnel
    esp=aes128-sha1
    ike=aes128-sha-modp1024
    left=10.1.0.7
    leftnexthop=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    rightsubnetwithin=0.0.0.0/0
    auto=add



Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
received Vendor ID payload [RFC 3947]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Aug 13 14:34:47 vpn0 pluto[11135]: packet from 209.240.75.80:500:
received Vendor ID payload [Dead Peer Detection]
Aug 13 14:34:47 vpn0 pluto[11135]: "L2TP"[1] 209.240.75.80 #1:
responding to Main Mode from unknown peer 209.240.75.80
Aug 13 14:34:47 vpn0 pluto[11135]: "L2TP"[1] 209.240.75.80 #1:
NAT-Traversal: Result using RFC 3947: both are NATed
Aug 13 14:34:47 vpn0 pluto[11135]: "L2TP"[1] 209.240.75.80 #1:
ignoring informational payload, type IPSEC_INITIAL_CONTACT
Aug 13 14:34:47 vpn0 pluto[11135]: "L2TP"[1] 209.240.75.80 #1: Peer ID
is ID_IPV4_ADDR: '192.168.22.94'
Aug 13 14:34:47 vpn0 pluto[11135]: "L2TP"[2] 209.240.75.80 #1:
deleting connection "L2TP" instance with peer 209.240.75.80
{isakmp=#0/ipsec=#0}
Aug 13 14:34:47 vpn0 pluto[11135]: | NAT-T: new mapping 209.240.75.80:500/4500)
Aug 13 14:34:47 vpn0 pluto[11135]: "L2TP"[2] 209.240.75.80:4500 #1:
sent MR3, ISAKMP SA established
Aug 13 14:34:48 vpn0 pluto[11135]: "L2TP"[2] 209.240.75.80:4500 #1:
cannot respond to IPsec SA request because no connection is known for
209.240.75.7/32===10.1.0.7:4500:17/1701...209.240.75.80:4500[192.168.22.94]:17/%any===192.168.22.94/32
Aug 13 14:34:48 vpn0 pluto[11135]: "L2TP"[2] 209.240.75.80:4500 #1:
sending encrypted notification INVALID_ID_INFORMATION to
209.240.75.80:4500
Aug 13 14:34:51 vpn0 pluto[11135]: "L2TP"[2] 209.240.75.80:4500 #1:
Quick Mode I1 message is unacceptable because it uses a previously
used Message ID 0xfa3ea0ca (perhaps this is a duplicated packet)
Aug 13 14:34:51 vpn0 pluto[11135]: "L2TP"[2] 209.240.75.80:4500 #1:
sending encrypted notification INVALID_MESSAGE_ID to
209.240.75.80:4500
Aug 13 14:34:54 vpn0 pluto[11135]: "L2TP"[2] 209.240.75.80:4500 #1:
Quick Mode I1 message is unacceptable because it uses a previously
used Message ID 0xfa3ea0ca (perhaps this is a duplicated packet)
Aug 13 14:34:54 vpn0 pluto[11135]: "L2TP"[2] 209.240.75.80:4500 #1:
sending encrypted notification INVALID_MESSAGE_ID to
209.240.75.80:4500


This is the output of "ipsec statusall" after making a connection attempt:

000 Status of IKEv1 pluto daemon (strongSwan 4.3.2):
000 interface lo/lo ::1:500
000 interface lo/lo 127.0.0.1:4500
000 interface lo/lo 127.0.0.1:500
000 interface eth0/eth0 10.1.0.7:4500
000 interface eth0/eth0 10.1.0.7:500
000 interface tun_bcps/tun_bcps 172.20.1.9:4500
000 interface tun_bcps/tun_bcps 172.20.1.9:500
000 interface tun_nimble/tun_nimble 172.20.1.11:4500
000 interface tun_nimble/tun_nimble 172.20.1.11:500
000 %myid = (none)
000 loaded plugins: random pubkey openssl hmac gmp
000 debug options: none
000
000 "L2TP": 10.1.0.7:17/1701---10.1.0.254...%any:17/%any==={0.0.0.0/0};
unrouted; eroute owner: #0
000 "L2TP":   ike_life: 10800s; ipsec_life: 3600s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 3
000 "L2TP":   policy: PSK+ENCRYPT+TUNNEL+DONTREKEY; prio: 32,0;
interface: eth0;
000 "L2TP":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "L2TP"[2]: 10.1.0.7:4500:17/1701---10.1.0.254...209.240.75.80:4500[192.168.22.94]:17/%any==={0.0.0.0/0};
unrouted; eroute owner: #0
000 "L2TP"[2]:   ike_life: 10800s; ipsec_life: 3600s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 3
000 "L2TP"[2]:   policy: PSK+ENCRYPT+TUNNEL+DONTREKEY; prio: 32,0;
interface: eth0;
000 "L2TP"[2]:   newest ISAKMP SA: #1; newest IPsec SA: #0;
000 "L2TP"[2]:   IKE proposal: AES_CBC_256/HMAC_SHA1/MODP_1024
000
000 #1: "L2TP"[2] 209.240.75.80:4500 STATE_MAIN_R3 (sent MR3, ISAKMP
SA established); EVENT_SA_EXPIRE in 3566s; newest ISAKMP
000