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

Tue Dec 14 10:04:39 CET 2010

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

On Dec 14, 2010, at 9:24 AM, Ulysse 31 wrote:

> 2010/11/24 Ulysse 31 <ulysse31 at gmail.com>:
>> 2010/11/22 Ulysse 31 <ulysse31 at gmail.com>:
>>> Hi all,
>>> 
>>> I have a strongswan with L2TP working with XP roadwarrior clients/ osx
>>> clients and iphone on one gateway with a public IP.Had to enable
>>> --enable-nat-transport but it works great.
>>> Now I have a second configuration, which is like :
>>> 
>>>     <client>
>>>          |
>>> <NAT Gateway>
>>>          |
>>>   <Internet >
>>>          |
>>> <NAT Gateway (cisco ASA 5505)>
>>>          |
>>> <Strongswan Server>
>>>          |
>>>    <LAN>
>>> 
>>> It is the almost the same configuration, the main big difference comes
>>> from the strongswan server that is NATed. The cisco ASA as no VPN
>>> feature enable, it is used like a simple NAT gateway, redirecting one
>>> public IP to the internal IP using a static NAT. all IP (TCP/UDP), esp
>>> and AH protocol is allowed. here is the first example of configuration
>>> used :
>>> 
>>> config setup
>>>       plutodebug="control"
>>>       strictcrlpolicy=no
>>>       overridemtu=1410
>>>       nat_traversal=yes
>>>       charonstart=no
>>>       plutostart=yes
>>> 
>>> conn L2TP
>>>    authby=psk
>>>    pfs=no
>>>    auto=add
>>>    rekey=no
>>>    type=tunnel
>>>    left=yy.yy.yy.yy                      # Internal private IP
>>>    leftnexthop=XX.XX.XX.XX      # External IP address
>>>    leftprotoport=17/1701
>>>    leftfirewall=yes
>>>    right=%any
>>>    rightprotoport=17/%any
>>>    rightsubnetwithin=0.0.0.0/0
>>>    rightfirewall=yes
>>>    esp=aes128-sha1
>>>    ike=aes128-sha-modp1024
>>>    forceencaps=yes
>>> 
>>> Here is what I got in the logs (the aa.aa.aa.aa is the IP public
>>> address of the client, and bb.bb.bb.bb is its private address) :
>>> 
>>> 
>>> ---
>>> Nov 20 11:51:35 src@<stronswanserv> pluto[26142]: "L2TP"[2]
>>> aa.aa.aa.aa:4500 #4: cannot respond to IPsec SA request because no
>>> connection is known for
>>> XX.XX.XX.XX/32===yy.yy.yy.yy:4500:17/1701…aa.aa.aa.aa:4500[bb.bb.bb.bb]:17/%any==={bb.bb.bb.bb/32}
>>> Nov 20 11:51:38 src@<stronswanserv> pluto[26142]: "L2TP"[2]
>>> aa.aa.aa.aa:4500 #4: Quick Mode I1 message is unacceptable because it
>>> uses a previously used Message ID 0xfb7bef8d (perhaps this is a
>>> duplicated packet)
>>> Nov 20 11:51:38 src@<stronswanserv> pluto[26142]: "L2TP"[2]
>>> aa.aa.aa.aa:4500 #4: sending encrypted notification INVALID_MESSAGE_ID
>>> to aa.aa.aa.aa:4500
>>> Nov 20 11:51:38 src@<stronswanserv> pluto[26142]: | next event
>>> EVENT_NAT_T_KEEPALIVE in 13 seconds
>>> The "Quick Mode I1 message is unacceptable" is repeated several times
>>> ( retries from client ) and the ISAKMP is never established, then it
>>> times out.
>>> ---
>>> 
>>> 
>>> So next I tried with adding "leftsubnet=XX.XX.XX.XX/32" on the conn
>>> L2TP config. which allowed me to establish ISAKMP, but then I have on
>>> the logs :
>>> 
>>> 
>>> ---
>>> Nov 20 11:52:58 src@<stronswanserv> pluto[26339]: |
>>> preparse_isakmp_policy: peer requests PSK authentication
>>> ...
>>> Nov 20 11:52:58 src@<stronswanserv> pluto[26339]: "L2TP"[1]
>>> aa.aa.aa.aa #4: responding to Main Mode from unknown peer aa.aa.aa.aa
>>> Nov 20 11:52:59 src@<stronswanserv> pluto[26339]: "L2TP"[1]
>>> aa.aa.aa.aa #4: NAT-Traversal: Result using RFC 3947: both are NATed
>>> Nov 20 11:52:59 src@<stronswanserv> pluto[26339]: "L2TP"[1]
>>> aa.aa.aa.aa #4: Peer ID is ID_IPV4_ADDR: 'bb.bb.bb.bb'
>>> Nov 20 11:52:59 src@<stronswanserv> pluto[26339]: "L2TP"[2]
>>> aa.aa.aa.aa #4: deleting connection "L2TP" instance with peer
>>> aa.aa.aa.aa {isakmp=#0/ipsec=#0}
>>> Nov 20 11:52:59 src@<stronswanserv> pluto[26339]: "L2TP"[2]
>>> aa.aa.aa.aa:4500 #4: sent MR3, ISAKMP SA established
>>> Nov 20 11:52:59 src@<stronswanserv> pluto[26339]: "L2TP"[2]
>>> aa.aa.aa.aa:4500 #4: ignoring informational payload, type
>>> IPSEC_INITIAL_CONTACT
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: "L2TP"[2]
>>> aa.aa.aa.aa:4500 #5: NAT-Traversal: received 2 NAT-OA. using first,
>>> ignoring others
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: "L2TP"[2]
>>> aa.aa.aa.aa:4500 #5: responding to Quick Mode
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: |
>>> kernel_alg_esp_auth_keylen(auth=2, sadb_aalg=3): a_keylen=20
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: |
>>> install_inbound_ipsec_sa() checking if we can route
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: | route owner of
>>> "L2TP"[2] aa.aa.aa.aa:4500 unrouted: NULL; eroute owner: NULL
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: | add inbound eroute
>>> aa.aa.aa.aa/32:57947 -> XX.XX.XX.XX/32:1701 =>
>>> tun.10000 at yy.yy.yy.yy:17
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: | inserting event
>>> EVENT_RETRANSMIT, timeout in 10 seconds for #5
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: | next event
>>> EVENT_NAT_T_KEEPALIVE in 6 seconds
>>> ...
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: "L2TP"[2]
>>> aa.aa.aa.aa:4500 #4: ignoring informational payload, type
>>> INVALID_HASH_INFORMATION
>>> Nov 20 11:53:00 src@<stronswanserv> pluto[26339]: "L2TP"[2]
>>> aa.aa.aa.aa:4500 #4: received Delete SA payload: deleting ISAKMP State
>>> #4
>>> ---
>>> 
>>> 
>>> I have tried different flags on the conn settings that may helped me
>>> (forceencaps=yes, type=transport instead of type=tunnel ). I really
>>> don't see why does it act like this on this machine. this machine (the
>>> strongswan server) is quite particular, since it runs a devil-linux
>>> distribution (livecd), that i had to rebuild in order to add the
>>> --enable-nat-transport on the strongswan script build, it uses
>>> strongswan 4.2.16, is there a way to check if the binary is really
>>> with the --enable-nat-transport ?
>>> Does someone have an hint on what I can do in order to make it work ?
>>> please help !
>>> 
>>> --
>>> Ulysse31
>>> 
>> 
>> Hi again,
>> 
>> I really need help, if somebody has some ideas ...
>> If somebody needs more logs/outputs/informations, please let me know.
>> Thanks again.
>> 
>> 
>> --
>> Gomes do Vale Victor
>> Ingénieur Systèmes, Réseaux et Securité
>> 
> 
> still having the problem and found no solution ... please help !
> 
> 
> -- 
> Ulysse31
> 
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users