[strongSwan] Cisco brings up the tunnel, but Linux not --- AH only

Andreas Steffen andreas.steffen at strongswan.org
Wed May 18 14:55:29 CEST 2011


Hmmm,

000 "vtest":   ESP/AH proposal: 3DES_CBC/HMAC_MD5/<N/A>

I see that this is a configuration problem with the
rarely used AH option, dating back to Free/SWAN times.

As far as I remember strongSwan always proposes SHA-1
irrespective of the HMAC algorithm you define. In
your case, although you specify

   auth=ah
   esp=3des-md5

in ipsec.conf, esp=3des-sha1 will be proposed via IKE.

Regards

Andreas

On 05/18/2011 12:56 PM, Zoltan wrote:
> Hi Andreas,
>
> Thank you for your answer. I switched on
>      auth=ah
>
> and I see the AUTHENTICATE difference in the output:
>      "initiating Quick Mode PSK+ENCRYPT+AUTHENTICATE+TUNNEL+UP",
>
> but alas, it didn't help. Actually, I don't see any
> change in the result (auth.log)
>      NO_PROPOSAL_CHOSEN
>      "perhaps peer likes no proposal".
>
>
> When the Cisco sets up the tunnel, it works fine.
> My 'ipsec statusall" shows something similar:
>
> 000 "vtest": ...96/27===...125  ...249===10.44.206.0/24; erouted; eroute owner: #2
> 000 "vtest":   ike_life: 86400s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
> 000 "vtest":   policy: PSK+ENCRYPT+AUTHENTICATE+TUNNEL; prio: 27,24; interface: br1:125;
> 000 "vtest":   newest ISAKMP SA: #1; newest IPsec SA: #2;
> 000 "vtest":   IKE proposal: 3DES_CBC/HMAC_MD5/MODP_1024
> 000 "vtest":   ESP/AH proposal: 3DES_CBC/HMAC_MD5/<N/A>
> 000 #2: "vtest" STATE_QUICK_R2 (IPsec SA established);
>      EVENT_SA_REPLACE in 3191s; newest IPSEC; eroute owner
> 000 #2: "vtest" ah.4b39583 at 6...249 ah.3cb41d94 at 1....125 esp.4c8152ef at ...249
>      (713 bytes, 133s ago) esp.f0adaa0a at ...125 (764 bytes, 132s ago); tunnel
> 000 #1: "vtest" STATE_MAIN_R3 (sent MR3, ISAKMP SA established)
>
> Maybe this asymmetric working comes from some unusual
> setting of the Cisco, and I won't be able to eliminate it
> without their cooperation.
>
> So, thank you again for your help!
> Zoltan
>
>
> =================
>    Andreas Steffen<andreas.steffen at strongswan.org>, wrote:
>
>    Hi,
>
> if you observe AH packets this means that ESP is used for encryption
> only (without optional ESP MAC) and authentication is done on top of ESP
> via AH. You can achieve the same with strongSwan as an initiator if
> you set
>
>     auth=ah
>
> Best regards
>
> Andreas
>
> On 05/17/2011 05:31 PM, Zoltan wrote:
>> Hi Everyone,
>>
>> The IPSEC traffic works fine between my strongSwan gateway
>> (and my clients) and the Cisco gateway/clients on the other side.
>> However, I cannot fully initiate it. It stops:
>>
>> 002 "vtest" #1: initiating Main Mode
>> 104 "vtest" #1: STATE_MAIN_I1: initiate
>> 106 "vtest" #1: STATE_MAIN_I2: sent MI2, expecting MR2
>> 003 "vtest" #1: ignoring Vendor ID payload [Cisco-Unity]
>> 003 "vtest" #1: received Vendor ID payload [Dead Peer Detection]
>> 003 "vtest" #1: ignoring Vendor ID payload [b1d915cbf5b7575752babd9fbc1f897a]
>> 003 "vtest" #1: received Vendor ID payload [XAUTH]
>> 108 "vtest" #1: STATE_MAIN_I3: sent MI3, expecting MR3
>> 002 "vtest" #1: Peer ID is ID_IPV4_ADDR: 'XXXa.b.c.dXXX'
>> 002 "vtest" #1: ISAKMP SA established
>> 004 "vtest" #1: STATE_MAIN_I4: ISAKMP SA established
>> 002 "vtest" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#1}
>> 112 "vtest" #2: STATE_QUICK_I1: initiate
>> 010 "vtest" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
>> ...
>> 010 "vtest" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
>> 031 "vtest" #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 "vtest" #2: starting keying attempt 2 of at most 3, but releasing whack
>>
>> ===
>> My config works fine, if the otherside Cisco gateway (or its clients)
>> initiate the traffic. My ipsec.conf is very simple (No NAT).
>>
>> What is strange for me is that on a router of our company I see
>> only AH packets, but no ESP, when the tunnel works fine.
>> (after some UDP 500 IKE traffic of course).
>>
>> # ipsec.conf - strongSwan IPsec configuration file
>> # basic configuration
>> config setup
>>           # plutodebug=all
>>           # crlcheckinterval=600
>>           # strictcrlpolicy=yes
>>           # cachecrls=yes
>>           # nat_traversal=yes
>>           charonstart=yes
>>           plutostart=yes
>>           charondebug=all
>>           ##plutodebug="controlmore natt parsing private"
>>           plutodebug=all
>>
>> conn vtest
>>           auto=add
>>           keyexchange=ikev1
>>           authby=psk
>>           ##auth=ah
>>           #
>>           left=M.N.O.125
>>           leftsubnet=M.N.O.96/27
>>           #
>>           right=XXXa.b.c.dXXX
>>           rightsubnet=10.14.140.0/24
>>           #
>>           ike=3des-md5-modp1024!
>>           esp=3des-md5!
>>           ikelifetime=86400
>>           pfs=no
>>
>> Can you help me to understand what happens?
>> (Omitting the strict !s from the config doesn't help.)
>> Regards
>> Zoltan

======================================================================
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]==




More information about the Users mailing list