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

[Snitgen, John]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20081028/df1c78af/attachment-0001.html