OpenSwan IPSec phase #2 complications

Question

Phase #1 (IKE) succeeds without any problems (verified at the target host).
Phase #2 (IPSec), however, is erroneous at some point (apparently due to misconfiguration on localhost).

This should be an IPSec-only connection. I am using OpenSwan on Debian. The error log reads the following (the actual IP-addr. of the remote endpoint has been modified):

pluto[30868]: "x" #2: initiating Quick Mode PSK+ENCRYPT+PFS+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#1 msgid:5ece82ee proposal=AES(12)_256-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_DH22}
pluto[30868]: "x" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
pluto[30868]: "x" #1: received and ignored informational message
pluto[30868]: "x" #1: the peer proposed: 0.0.0.0/0:0/0 -> 0.0.0.0/0:0/0
pluto[30868]: "x" #3: responding to Quick Mode proposal {msgid:a4f5a81c}
pluto[30868]: "x" #3: us: 192.168.1.76<192.168.1.76>[+S=C]
pluto[30868]: "x" #3: them: 222.222.222.222<222.222.222.222>[+S=C]===10.196.0.0/17
pluto[30868]: "x" #3: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
pluto[30868]: "x" #3: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
pluto[30868]: "x" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
pluto[30868]: "x" #1: received and ignored informational message
pluto[30868]: "x" #3: next payload type of ISAKMP Hash Payload has an unknown value: 97 X pluto[30868]: "x" #3: malformed payload in packet
pluto[30868]: | payload malformed after IV

I am behind NAT and this is all coming from wlan2. Here are the details:

default via 192.168.1.254 dev wlan2 proto static
169.254.0.0/16 dev wlan2 scope link metric 1000
192.168.1.0/24 dev wlan2 proto kernel scope link src 192.168.1.76 metric 2

Output of ipsec verify:

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.6.37/K3.2.0-24-generic (netkey)
Checking for IPsec support in kernel [OK]
SAref kernel support [N/A]
NETKEY: Testing XFRM related proc values [OK]
[OK]
[OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for NAT-T on udp 4500 [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADEing [OK]
Checking for 'ip' command [OK]
Checking /bin/sh is not /bin/dash [WARNING]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]

This is what happens when I run ipsec auto --up x:

104 "x" #1: STATE_MAIN_I1: initiate
003 "x" #1: received Vendor ID payload [RFC 3947] method set to=109
106 "x" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "x" #1: received Vendor ID payload [Cisco-Unity]
003 "x" #1: received Vendor ID payload [Dead Peer Detection]
003 "x" #1: ignoring unknown Vendor ID payload [502099ff84bd4373039074cf56649aad]
003 "x" #1: received Vendor ID payload [XAUTH]
003 "x" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i am NATed
108 "x" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "x" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1024}
117 "x" #2: STATE_QUICK_I1: initiate
010 "x" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "x" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "x" #2: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
000 "x" #2: starting keying attempt 2 of at most 3, but releasing whack

More debug info from ipsec auto --status:

000 using kernel interface: netkey
000 interface lo/lo ::1
000 interface wlan2/wlan2 192.168.1.76
000 interface wlan2/wlan2 192.168.1.76
000 %myid = (none)
000 debug raw+crypt+parsing+emitting+control+lifecycle+klips+dns+oppo+controlmore+pfkey+nattraversal+x509+dpd+oppoinfo
000
000 virtual_private (%priv):
000 - allowed 2 subnets: 10.196.0.0/17, 192.168.1.0/24
000 - disallowed 0 subnets:
000 WARNING: Disallowed subnets in virtual_private= is empty. If you have
000 private address space in internal use, it should be excluded!
000
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,4,36} trans={0,4,1536} attrs={0,4,2048}
000
000 "x": 192.168.1.0/24===192.168.1.76[+S=C]...222.222.222.222<222.222.222.222>[+S=C]===10.196.0.0/17; unrouted; eroute owner: #0
000 "x": myip=unset; hisip=unset;
000 "x": ike_life: 28800s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
000 "x": policy: PSK+ENCRYPT+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,17; interface: wlan2;
000 "x": dpd: action:clear; delay:0; timeout:0;
000 "x": newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "x": ESP algorithms wanted: AES(12)_256-SHA1(2)_000; pfsgroup=DH22(22); flags=-strict
000 "x": ESP algorithms loaded: AES(12)_256-SHA1(2)_160

Even more debug info (plutodebug="all") coming from /var/log/auth.log:

pluto[26439]: | peer client is subnet 0.0.0.0/0
pluto[26439]: | peer client protocol/port is 0/0
pluto[26439]: | our client is subnet 0.0.0.0/0
pluto[26439]: | our client protocol/port is 0/0
pluto[26439]: "x" #1: the peer proposed: 0.0.0.0/0:0/0 -> 0.0.0.0/0:0/0
pluto[26439]: | find_client_connection starting with x
pluto[26439]: | looking for 0.0.0.0/0:0/0 -> 0.0.0.0/0:0/0
pluto[26439]: | concrete checking against sr#0 192.168.1.0/24 -> 10.196.0.0/17
pluto[26439]: | match_id a=222.222.222.222
pluto[26439]: | b=222.222.222.222
pluto[26439]: | results matched
pluto[26439]: | trusted_ca called with a=(empty) b=(empty)
pluto[26439]: | fc_try trying x:0.0.0.0/0:0/0 -> 0.0.0.0/0:0/0 vs x:192.168.1.0/24:0/0 -> 10.196.0.0/17:0/0
pluto[26439]: | our client(192.168.1.0/24) not in our_net (0.0.0.0/0)
pluto[26439]: | fc_try concluding with none [0]
pluto[26439]: | fc_try x gives none
pluto[26439]: | find_host_pair: comparing to 192.168.1.76:500 222.222.222.222:500
pluto[26439]: | checking hostpair 192.168.1.0/24 -> 10.196.0.0/17 is not found
pluto[26439]: | concluding with d = none
pluto[26439]: | using (something - hopefully the IP we or they are NAT'ed to) for transport mode connection "x"

I have enabled NAT traversal in ipsec.conf accordingly. Here are the settings relative to the connection in question:

version 2.0

config setup

plutoopts="--perpeerlog"
plutoopts="--interface=wlan2"
dumpdir=/var/run/pluto/
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
oe=off
protostack=netkey

conn x

authby=secret  
pfs=yes  
auto=add  
phase2alg=aes256-sha1;dh22  
keyingtries=3  
ikelifetime=8h  
type=transport  
left=192.168.1.76  
leftsubnet=192.168.1.0/24  
leftprotoport=0/0  
right=222.222.222.222  
rightsubnet=10.196.0.0/17  
rightprotoport=0/0

Here are the specs provided by the other end that must be met for Phase #2:

encryption algorithm: AES (128 or 256 bit)
hash algorithm: SHA
local ident1 (addr/mask/prot/port): (10.196.0.0/255.255.128.0/0/0)
local ident2 (addr/mask/prot/port): (10.241.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (x.x.x.x/x.x.x.x/0/0) (internal network or localhost)
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS: DH group2

So, finally, what might be the cause of the issue that I am experiencing? Thank you.

Solution

You'll want to get the remote end to enable NAT-T on their end of the connection as well.

IPSec communication cryptographically signs the entire packet - any change to the IP header will invalidate that signature. NAT works by rewriting the source and/or destination IP fields; having NAT on either end of the connection means that every packet is having the header changed in transit; the source is changed on packets leaving your 192.168 network, and the destination is changed on inbound packets.

NAT-T counteracts this by encapsulating the entire ESP packet in a new UDP packet. The UDP packet can safely have its headers mangled to the satisfaction of any NAT devices, while the ESP payload will make the entire trip unchanged. The remote node will need to enable this to protect the packets they're sending your way from the NAT modifications, and you'll both need to be allowing UDP port 4500.

This may not be the only issue in the configuration of the VPN tunnel, but it would certainly explain a malformed payload message; give it a shot, and let us know if any further issues come up!

Comments

[ravi yarlagadda]

Is NAT-T enabled on the remote peer?

[XXL]

@ShaneMadden: unsure, but I think it's disabled, as 192.168.x.x was not in use

[XXL]

Unfortunately, as it turns out, the remote end is not behind a NAT device, so enabling NAT traversal will probably not help in this case. However, UDP port 4500 was indeed not forwarded on our end (as it passed ipsec verify with NAT-T enabled) - it is now. Sadly, the outcome is still the same. Is there anything else I can do to debug this?

[ravi yarlagadda]

As explained in my answer, NAT-T in necessary on both ends of the connection if either end has NAT, because every packet sent by either side will be altered by the NAT on one end.