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 <ulyss...@gmail.com>: >> 2010/11/22 Ulysse 31 <ulyss...@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.10...@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@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users