[Openswan Users] Tunnel failing to come up

Neal Murphy neal.p.murphy at alum.wpi.edu
Fri Jan 23 12:52:30 EST 2015


On Friday, January 23, 2015 02:48:14 AM Managed Pvt nets wrote:
> On 23/01/2015 4:17:47 AM, "Managed Pvt nets" <mpn at icabs.co.zw> wrote:
> >There interesting part is the part in my /var/log/pluto.log where it
> >appears to be "ignoring Vendor ID payload".
> 
> After a few changes, here is what I am getting now:

Yesterday you were reaching STATE_MAIN_I4 and were sending QUICK-I1. Today you 
aren't getting past STATE_MAIN_R2. Whatever you changed since yesterday, 
change it back.

Might be a good time to review the versions of the software you're using at 
your end. And what's at the remote end, if possible. (Is the remote trying to 
speak LT2P?)

This is fast approaching the limit of my abilities; I've not had to debug so 
deeply before.

> 
> #tail -f /var/log/pluto.log
> "tunnel1" #29: responding to Main Mode
> "tunnel1" #29: transition from state STATE_MAIN_R0 to state
> STATE_MAIN_R1
> "tunnel1" #29: STATE_MAIN_R1: sent MR1, expecting MI2
> "tunnel1" #29: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
> both are NATed
> "tunnel1" #29: transition from state STATE_MAIN_R1 to state
> STATE_MAIN_R2
> "tunnel1" #29: STATE_MAIN_R2: sent MR2, expecting MI3
> "tunnel1" #28: max number of retransmissions (2) reached STATE_MAIN_R2
> "tunnel1" #29: max number of retransmissions (2) reached STATE_MAIN_R2
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload [MS NT5
> ISAKMPOAKLEY 00000006]
> packet from RIGHT_PUBLIC_IP:500: received Vendor ID payload [RFC 3947]
> method set to=109
> packet from RIGHT_PUBLIC_IP:500: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload
> [FRAGMENTATION]
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload
> [MS-Negotiation Discovery Capable]
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload
> [Vid-Initial-Contact]
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload [IKE CGA
> version 1]
> "tunnel1" #30: responding to Main Mode
> "tunnel1" #30: transition from state STATE_MAIN_R0 to state
> STATE_MAIN_R1
> "tunnel1" #30: STATE_MAIN_R1: sent MR1, expecting MI2
> "tunnel1" #30: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
> both are NATed
> "tunnel1" #30: transition from state STATE_MAIN_R1 to state
> STATE_MAIN_R2
> "tunnel1" #30: STATE_MAIN_R2: sent MR2, expecting MI3
> "tunnel1" #30: max number of retransmissions (2) reached STATE_MAIN_R2
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload [MS NT5
> ISAKMPOAKLEY 00000006]
> packet from RIGHT_PUBLIC_IP:500: received Vendor ID payload [RFC 3947]
> method set to=109
> packet from RIGHT_PUBLIC_IP:500: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload
> [FRAGMENTATION]
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload
> [MS-Negotiation Discovery Capable]
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload
> [Vid-Initial-Contact]
> packet from RIGHT_PUBLIC_IP:500: ignoring Vendor ID payload [IKE CGA
> version 1]
> "tunnel1" #31: responding to Main Mode
> ----
> #ipsec auto --status
> 000 "tunnel1":
> 192.168.0.0/24===192.168.0.2<192.168.0.2>[LEFT_PUBLIC_IP,+S=C]---192.168.0.
> 1...192.168.0.1---RIGHT_PUBLIC_IP<RIGHT_PUBLIC_IP>[+S=C]===192.168.10.0/24;
> prospective erouted; eroute owner: #0
> 000 "tunnel1":     myip=unset; hisip=unset;
> 000 "tunnel1":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
> 540s; rekey_fuzz: 100%; keyingtries: 0
> 000 "tunnel1":   policy:
> PSK+ENCRYPT+TUNNEL+PFS+UP+AGGRESSIVE+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD;
> prio: 24,24; interface: eth1;
> 000 "tunnel1":   newest ISAKMP SA: #0; newest IPsec SA: #0;
> 000 "tunnel1":   IKE algorithms wanted:
> 3DES_CBC(5)_000-SHA1(2)_000-MODP1536(5),
> 3DES_CBC(5)_000-SHA1(2)_000-MODP1024(2); flags=-strict
> 000 "tunnel1":   IKE algorithms found:
> 3DES_CBC(5)_192-SHA1(2)_160-MODP1536(5),
> 3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)
> 000 "tunnel1":   ESP algorithms wanted: 3DES(3)_000-SHA1(2)_000;
> flags=-strict
> 000 "tunnel1":   ESP algorithms loaded: 3DES(3)_192-SHA1(2)_160
> 000
> 000 #1: "tunnel1":500 STATE_AGGR_I1 (sent AI1, expecting AR1);
> EVENT_RETRANSMIT in 26s; nodpd; idle; import:admin initiate
> 000 #1: pending Phase 2 for "tunnel1" replacing #0
> 000
> ===
> 
> I am a bit unsure how to proceed from here.
> 
> MPN.


More information about the Users mailing list