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

Wed Dec 15 09:44:59 CET 2010

Tested with windows XP client, same result :
"L2TP"[2] xx.xx.xx.xx:4500 #81: ignoring informational payload, type
INVALID_HASH_INFORMATION

So, it seams that not only racoon clients are affected ...

2010/12/14 Mohit Mehta <mohit.mehta at vyatta.com>:
> 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
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>

-- 
Gomes do Vale Victor
Ingénieur Systèmes, Réseaux et Securité