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

2011-05-18 Thread Andreas Steffen 
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

 ___
 Users mailing list
 Users@lists.strongswan.org
 https://lists.strongswan.org/mailman/listinfo/users


-- 
==
Andreas Steffen andreas.stef...@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@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

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

2011-05-18 Thread Zoltan 
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@6...249 ah.3cb41d94@1125 esp.4c8152ef@...249
(713 bytes, 133s ago) esp.f0adaa0a@...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.stef...@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

 ___
 Users mailing list
 Users@lists.strongswan.org
 https://lists.strongswan.org/mailman/listinfo/users


-- 
==
Andreas Steffen andreas.stef...@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@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

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

2011-05-18 Thread Andreas Steffen 
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@6...249 ah.3cb41d94@1125 esp.4c8152ef@...249
  (713 bytes, 133s ago) esp.f0adaa0a@...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 Steffenandreas.stef...@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.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org
Institute for Internet Technologies and Applications