[strongSwan] strongswan/L2TP and NAT-T transport with both NATed

[Mohit Mehta]

Hi Andreas,

Thanks for jumping in on this and providing such detailed explanation.

Although I wonder that this problem is specific to racoon's inter-operation with Strongswan since atleast one of the users on our forums reported similar problems while he was trying to connect using L2TP/IPsec from both Windows Vista and Windows XP machines behind a natted router to a strongswan server that was also behind a natter router - 

http://www.vyatta.org/forum/viewtopic.php?p=48296#48296

The user also reported that he had the same configuration working with openswan before so I'm assuming he had his setup right. 

More specifically, in the above mentioned post, these are the interesting lines in the log dump -

ipsec statusall

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 192.168.200.18:4500 
000 interface eth0/eth0 192.168.200.18:500 
000 %myid = (none) 
000 loaded plugins: curl ldap random pubkey openssl hmac gmp 
000 debug options: control 
000 
000 "remote-access-mac-zzz": 192.168.200.18:17/1701---192.168.200.1...%virtual:17/%any===?; unrouted; eroute owner: #0 
000 "remote-access-mac-zzz":   ike_life: 3600s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3 
000 "remote-access-mac-zzz":   dpd_action: clear; dpd_delay: 15s; dpd_timeout: 45s; 
000 "remote-access-mac-zzz":   policy: PSK+ENCRYPT+TUNNEL+DONTREKEY; prio: 32,32; interface: eth0; 
000 "remote-access-mac-zzz":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
000 "remote-access-win-aaa": 192.168.200.18:17/1701---192.168.200.1...%virtual:17/1701===?; unrouted; eroute owner: #0 
000 "remote-access-win-aaa":   ike_life: 3600s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3 
000 "remote-access-win-aaa":   dpd_action: clear; dpd_delay: 15s; dpd_timeout: 45s; 
000 "remote-access-win-aaa":   policy: PSK+ENCRYPT+TUNNEL+DONTREKEY; prio: 32,32; interface: eth0; 
000 "remote-access-win-aaa":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
000 


messages in the log -

Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[1] 121.xx.xxx.219 #1: responding to Main Mode from unknown peer 121.xx.xxx.219 
:Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[1] 121.xx.xxx.219 #1: Oakley Transform [AES_CBC (256), HMAC_SHA1, ECP_384] refused due to strict flag 
Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[1] 121.xx.xxx.219 #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, ECP_256] refused due to strict flag 
Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[1] 121.xx.xxx.219 #1: Oakley Transform [3DES_CBC (192), HMAC_SHA1, MODP_2048] refused due to strict flag 
Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[1] 121.xx.xxx.219 #1: NAT-Traversal: Result using RFC 3947: both are NATed 
Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[1] 121.xx.xxx.219 #1: Peer ID is ID_IPV4_ADDR: '192.168.1.9' 
Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[2] 121.xx.xxx.219 #1: deleting connection "remote-access-mac-zzz" instance with peer 121.xx.xxx.219 {isakmp=#0/ipsec=#0} 
Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[2] 121.xx.xxx.219:27065 #1: sent MR3, ISAKMP SA established 
Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[2] 121.xx.xxx.219:27065 #1: cannot respond to IPsec SA request because no connection is known for 121.xx.xxx.195/32===192.168.200.18:4500:17/1701...121.xx.xxx.219:27065[192.168.1.9]:17/%any===192.168.1.9/32 
Jun 20 19:55:33 vyatta pluto[12466]: "remote-access-mac-zzz"[2] 121.xx.xxx.219:27065 #1: sending encrypted notification INVALID_ID_INFORMATION to 121.xx.xxx.219:27065 
Jun 20 19:55:35 vyatta pluto[12466]: "remote-access-mac-zzz"[2] 121.xx.xxx.219:27065 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet) 


Also, is there an example of Strongswan being connected from a roadwarrior when both are behind a Natted router in transport mode? I could find examples of server and client behind NAT in tunnel mode but not in transport mode which is the case when using IPsec/L2TP .

Ulysse and Benoit,

Could either of you please confirm that you see this problem only when connecting using racoon or does it happen with Windows as well.?

Thanks,
Mohit

----- Original Message -----
> Hello Benoit,
> 
> RFC 3947 "Negotiation of NAT-Traversal in the IKE" does not specify
> explicitly whether the additional NAT-OA payloads must be part of
> the hash:
> 
> >----------------------------------------------------------------------
> The following example is of Quick Mode using NAT-OA payloads:
> 
> Initiator Responder
> ------------ ------------
> HDR*, HASH(1), SA, Ni, [, KE]
> [, IDci, IDcr ]
> [, NAT-OAi, NAT-OAr] -->
> <-- HDR*, HASH(2), SA, Nr, [, KE]
> [, IDci, IDcr ]
> [, NAT-OAi, NAT-OAr]
> HDR*, HASH(3) -->
> ----------------------------------------------------------------------<
> 
> but the IKEv1 RFC 2409 specifies in section 5.5 "Phase 2 - Quick
> Mode":
> 
> >----------------------------------------------------------------------
> Quick Mode is defined as follows:
> 
> Initiator Responder
> ----------- -----------
> HDR*, HASH(1), SA, Ni
> [, KE ] [, IDci, IDcr ] -->
> <-- HDR*, HASH(2), SA, Nr
> [, KE ] [, IDci, IDcr ]
> HDR*, HASH(3) -->
> 
> Where: HASH(1) is the prf over the message id (M-ID) from the ISAKMP
> header concatenated with the entire message that follows the hash
> including !! ^^^^^^^^^^^^^^^^^
> all payload headers, but excluding any padding added for encryption.
> HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni,
> minus the payload header-- is added after M-ID but before the
> complete message. The addition of the nonce to HASH(2) is for a
> liveliness proof. HASH(3)-- for liveliness-- is the prf over the
> value zero represented as a single octet, followed by a concatenation
> of the message id and the two nonces-- the initiator's followed by
> the responder's-- minus the payload header. In other words, the
> hashes for the above exchange are:
> 
> HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
> HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
> IDcr )
> HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
> 
> With the exception of the HASH, SA, and the optional ID payloads,
> there are no payload ordering restrictions on Quick Mode. HASH(1) and
> HASH(2) may differ from the illustration above if the order of
> !! ^^^^^^^^^^
> payloads in the message differs from the illustrative example or if
> any optional payloads, for example a notify payload, have been
> !! ^^^^^^^^^^^^^^^^^^^^^
> chained to the message.
> ----------------------------------------------------------------------<
> 
> Thus in my opinion strongSwan is correct in including the optional
> NAT-OA payloads in the HASH and racoon is wrong in not doing so.
> 
> Best regards
> 
> Andreas
> 
> On 14.12.2010 10:04, Benoit Foucher wrote:
> > Hi Victor,
> >
> > I found a workaround for this INVALID_HASH_INFORMATION error by
> > hacking strongSwan's code but I doubt it's really correct (and I'm
> > running into another issue after :(). The problem is that raccoon
> > and strongSwan don't compute the HASH on the same data (raccoon
> > doesn't includes NAT-OA in the hash computation whereas strongSwan
> > does).
> >
> > See:
> >
> > https://lists.strongswan.org/pipermail/users/2010-December/005712.html
> >
> >  It would be good to figure out whether or not this is a strongSwan
> > or raccoon issue. If it's the later I'll submit a bug where
> > appropriate.
> >
> > Cheers, Benoit
> >
> 
> ======================================================================
> Andreas Steffen andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution! www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
> 
> _______________________________________________ Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users