[Openswan Users] NAT-T inter-op problem with Cisco?

[Snitgen, John]

Hello List,

I have been digging into this a little more.  It appears that the Cisco
in question here has multiple policies defined in its configuration, and
that that may be what is at the root of this problem.  Also, I'm leaning
toward an expiration of the IKE timer rather than a renegotiation of the
IPSec SA... both ends have the IKE set at 24 hours.  I suspect that as
long as the 'client' (Openswan end) initiates the IKE renegotiation,
everything works fine.  If the Cisco timer kicks off first however, it
fails to renegotiate because of the multiple policies defined on the
Cisco.  

 

This is just a guess at this point, I am going to do further testing to
try to confirm.  Both ends are currently configured to renegotiate the
IKE at 24 hours.  I am going to set two test units up against the Cisco
- one with a 23-hour IKE lifetime, and one with a 25-hour IKE lifetime
and see what happens.  I do not have control of the Cisco end, but I am
also working on getting the configuration cleaned up there so that there
is only one policy.

 

Thanks,

John

 

________________________________

From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
Behalf Of Snitgen, John
Sent: Tuesday, October 28, 2008 2:58 PM
To: users at openswan.org
Subject: [Openswan Users] NAT-T inter-op problem with Cisco?

 

Hello List,

I am seeing the following set of prints in my debug log (see below)
associated with a failure to renegotiate my VPN tunnel.  This happens on
the third re-negotiation of the SA after the initial establishment of
the VPN tunnel.  In other words, the tunnel is initiated and comes up
fine - in this example, the initial establishment of the tunnel occurred
at around 3:30 a.m..  The keylife=12h on the local side and is set to 6
hours on the remote end (remote end is a Cisco aggregator).  So the
scenario is as follows:  The tunnel comes up, it renegotiates at around
6 hours as it should, then again at 12 hours as it should (these
renegotiations are initiated by the Cisco), then at the 18 hour mark
this happens; xxx.xxx.xxx.xxx is the Cisco:

 

 

 

Oct 21 21:04:32 pluto[18772]: packet from xxx.xxx.xxx.xxx:500: received
Vendor ID payload [RFC 3947] method set to=110 

Oct 21 21:04:32 pluto[18772]: packet from xxx.xxx.xxx.xxx:500: ignoring
unknown Vendor ID payload
[bunchoflettersandnumberslike235lks6dkn78glknsoijf]

Oct 21 21:04:32 pluto[18772]: packet from xxx.xxx.xxx.xxx:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already
using method 110

Oct 21 21:04:32 pluto[18772]: packet from xxx.xxx.xxx.xxx:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but
already using method 110

Oct 21 21:04:32 pluto[18772]: "IPSECTUNNEL" #5: responding to Main Mode

Oct 21 21:04:32 pluto[18772]: "IPSECTUNNEL" #5: policy mandates Extended
Authentication (XAUTH) with PSK of responder (we are responder).
Attribute OAKLEY_AUTHENTICATION_METHOD

Oct 21 21:04:32 Last line repeated 1 time(s).

Oct 21 21:04:32 pluto[18772]: "IPSECTUNNEL" #5: policy mandates Extended
Authentication (XAUTH) with RSA of responder (we are responder).
Attribute OAKLEY_AUTHENTICATION_METHOD

Oct 21 21:04:32 pluto[18772]: "IPSECTUNNEL" #5: no acceptable Oakley
Transform

Oct 21 21:04:32 pluto[18772]: "IPSECTUNNEL" #5: sending notification
NO_PROPOSAL_CHOSEN to xxx.xxx.xxx.xxx:500

(then, it repeats)

Oct 21 21:04:42 pluto[18772]: packet from xxx.xxx.xxx.xxx:500: received
Vendor ID payload [RFC 3947] method set to=110 

Oct 21 21:04:42 pluto[18772]: packet from xxx.xxx.xxx.xxx:500: ignoring
unknown Vendor ID payload [samebunchoflettersandnumbersasthefirsttime2]

Oct 21 21:04:42 pluto[18772]: packet from xxx.xxx.xxx.xxx:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already
using method 110

Oct 21 21:04:42 pluto[18772]: packet from xxx.xxx.xxx.xxx:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but
already using method 110

Oct 21 21:04:42 pluto[18772]: "IPSECTUNNEL" #6: responding to Main Mode

Oct 21 21:04:42 pluto[18772]: "IPSECTUNNEL" #6: policy mandates Extended
Authentication (XAUTH) with PSK of responder (we are responder).
Attribute OAKLEY_AUTHENTICATION_METHOD

Oct 21 21:04:42 Last line repeated 1 time(s).

Oct 21 21:04:42 pluto[18772]: "IPSECTUNNEL" #6: policy mandates Extended
Authentication (XAUTH) with RSA of responder (we are responder).
Attribute OAKLEY_AUTHENTICATION_METHOD

Oct 21 21:04:42 pluto[18772]: "IPSECTUNNEL" #6: no acceptable Oakley
Transform

Oct 21 21:04:42 pluto[18772]: "IPSECTUNNEL" #6: sending notification
NO_PROPOSAL_CHOSEN to xxx.xxx.xxx.xxx:500

 

I am seeing this occur on multiple devices that are connecting to this
Cisco aggregator.  NAT-T is enabled on the Cisco aggregator (prime
suspect of the problem, based on these debug prints), and on the local
device.  I have tried disabling it on the local device since it is not
needed, but I need to have it enabled on the Cisco for other devices
that do need it.

 

Any idea on why the initial connection is successful, along with the
renegotiations at the first two 6 hour intervals, and then it fails in
this manner?  

 

 

Openswan KLIPS IPsec stack version: 2.4.6., I can provide more info if
needed.

 

Thanks,

John

 

 

 

 

 

 

 

 

 

________________________________

This e-mail message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information of Transaction
Network Services. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the
original message.



This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information of Transaction Network Services. Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20081103/7c82157e/attachment.html