[Openswan Users] Lots of errors since upgrading to 2.6.21, seemed ok for a day or so

Ted Kaczmarek tedkaz at optonline.net
Thu Apr 16 10:11:12 EDT 2009 

On Apr 15, 2009, at 9:33 AM, Ted Kaczmarek wrote:

> I am using a pair of Centos 4.7 machines with 2.6.9-78.0.13.ELsmp and
> 2.6.9-78.0.13.EL kernels respectively.
> I built the openswan rpms using rpmbuild and the supplied fedora.spec.
>
> For about a day or so everything seemed fine and this morning after a
> power hit I started to see issues.
>
> From Tcpdump
> phase 1 ? ident: [|ke] (len mismatch: isakmp 308/ip 384)
>
> From ipsec barf
>
> Apr 15 09:23:33 vpnsrv1 pluto[9147]: "tunnel1" #184: responding to
> Main Mode
> Apr 15 09:23:33 vpnsrv1 pluto[9147]: "tunnel1" #184: transition from
> state STATE_MAIN_R0 to state STATE_MAIN_R1
> Apr 15 09:23:33 vpnsrv1 pluto[9147]: "tunnel1" #184: STATE_MAIN_R1:
> sent MR1, expecting MI2
> Apr 15 09:23:33 vpnsrv1 pluto[9147]: "tunnel1" #179: Informational
> Exchange message must be encrypted
> Apr 15 09:23:33 vpnsrv1 pluto[9147]: "tunnel1" #184: transition from
> state STATE_MAIN_R1 to state STATE_MAIN_R2
> Apr 15 09:23:33 vpnsrv1 pluto[9147]: "tunnel1" #184: STATE_MAIN_R2:
> sent MR2, expecting MI3
> Apr 15 09:23:33 vpnsrv1 pluto[9147]: "tunnel1" #184: Main mode peer ID
> is ID_IPV4_ADDR: '142.34.84.222'
> Apr 15 09:23:33 vpnsrv1 pluto[9147]: "tunnel1" #184: transition from
> state STATE_MAIN_R2 to state STATE_MAIN_R3
> Apr 15 09:23:33 vpnsrv1 pluto[9147]: "tunnel1" #184: STATE_MAIN_R3:
> sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
> cipher=aes_128 prf=oakley_sha group=modp2048}
> Apr 15 09:23:35 vpnsrv1 pluto[9147]: "tunnel1" #179: Informational
> Exchange message must be encrypted
> Apr 15 09:23:43 vpnsrv1 pluto[9147]: "tunnel1" #179: retransmitting in
> response to duplicate packet; already STATE_MAIN_R3
> Apr 15 09:23:43 vpnsrv1 pluto[9147]: "tunnel1" #179: Informational
> Exchange message must be encrypted
> Apr 15 09:23:44 vpnsrv1 pluto[9147]: "tunnel1" #184: retransmitting in
> response to duplicate packet; already STATE_MAIN_R3
> Apr 15 09:23:49 vpnsrv1 pluto[9147]: "tunnel1" #179: Informational
> Exchange message must be encrypted
> Apr 15 09:23:52 vpnsrv1 pluto[9147]: "tunnel3" #176: max number of
> retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to
> our first Quick Mode message: perhaps peer likes no proposal
> Apr 15 09:23:52 vpnsrv1 pluto[9147]: "tunnel3" #176: starting keying
> attempt 19 of an unlimited number
> Apr 15 09:23:52 vpnsrv1 pluto[9147]: "tunnel3" #185: initiating Quick
> Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #176 {using
> isakmp#184 msgid:d2dfdec8 proposal=defaults
> pfsgroup=OAKLEY_GROUP_MODP2048}
> Apr 15 09:23:53 vpnsrv1 pluto[9147]: "tunnel1" #184: Informational
> Exchange message must be encrypted
> Apr 15 09:23:55 vpnsrv1 pluto[9147]: "tunnel1" #179: Informational
> Exchange message must be encrypted
> Apr 15 09:24:03 vpnsrv1 pluto[9147]: "tunnel1" #184: Informational
> Exchange message must be encrypted
> Apr 15 09:24:04 vpnsrv1 pluto[9147]: "tunnel1" #184: retransmitting in
> response to duplicate packet; already STATE_MAIN_R3
> Apr 15 09:24:17 vpnsrv1 pluto[9147]: "tunnel2" #177: max number of
> retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to
> our first Quick Mode message: perhaps peer likes no proposal
> Apr 15 09:24:17 vpnsrv1 pluto[9147]: "tunnel2" #177: starting keying
> attempt 20 of an unlimited number
> Apr 15 09:24:17 vpnsrv1 pluto[9147]: "tunnel2" #186: initiating Quick
> Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #177 {using
> isakmp#184 msgid:a5915d72 proposal=defaults
> pfsgroup=OAKLEY_GROUP_MODP2048}
> Apr 15 09:24:17 vpnsrv1 pluto[9147]: "tunnel1" #184: Informational
> Exchange message must be encrypted
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel6" #178: max number of
> retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to
> our first Quick Mode message: perhaps peer likes no proposal
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel6" #178: starting keying
> attempt 17 of an unlimited number
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel6" #187: initiating Quick
> Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #178 {using
> isakmp#184 msgid:2f962f49 proposal=defaults
> pfsgroup=OAKLEY_GROUP_MODP2048}
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: packet from 142.34.84.222:500:
> received Vendor ID payload [Openswan (this version) 2.6.21 ]
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: packet from 142.34.84.222:500:
> received Vendor ID payload [Dead Peer Detection]
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: packet from 142.34.84.222:500:
> received Vendor ID payload [RFC 3947] meth=109, but port floating is  
> off
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: packet from 142.34.84.222:500:
> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108,
> but port floating is off
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: packet from 142.34.84.222:500:
> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
> but port floating is off
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: packet from 142.34.84.222:500:
> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107,
> but port floating is off
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: packet from 142.34.84.222:500:
> ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel1" #188: responding to
> Main Mode
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel1" #188: transition from
> state STATE_MAIN_R0 to state STATE_MAIN_R1
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel1" #188: STATE_MAIN_R1:
> sent MR1, expecting MI2
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel1" #184: Informational
> Exchange message must be encrypted
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel1" #188: transition from
> state STATE_MAIN_R1 to state STATE_MAIN_R2
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel1" #188: STATE_MAIN_R2:
> sent MR2, expecting MI3
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel1" #188: Main mode peer ID
> is ID_IPV4_ADDR: '142.34.84.222'
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel1" #188: transition from
> state STATE_MAIN_R2 to state STATE_MAIN_R3
> Apr 15 09:24:22 vpnsrv1 pluto[9147]: "tunnel1" #188: STATE_MAIN_R3:
> sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
> cipher=aes_128 prf=oakley_sha group=modp2048}
> Apr 15 09:24:23 vpnsrv1 pluto[9147]: "tunnel4" #180: max number of
> retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to
> our first Quick Mode message: perhaps peer likes no proposal
> Apr 15 09:24:23 vpnsrv1 pluto[9147]: "tunnel4" #180: starting keying
> attempt 20 of an unlimited number
> Apr 15 09:24:23 vpnsrv1 pluto[9147]: "tunnel4" #189: initiating Quick
> Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #180 {using
> isakmp#188 msgid:10ba7815 proposal=defaults
> pfsgroup=OAKLEY_GROUP_MODP2048}
> Apr 15 09:24:27 vpnsrv1 pluto[9147]: "tunnel1" #184: Informational
> Exchange message must be encrypted
> Apr 15 09:24:29 vpnsrv1 pluto[9147]: "tunnel7" #181: max number of
> retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to
> our first Quick Mode message: perhaps peer likes no proposal
> Apr 15 09:24:29 vpnsrv1 pluto[9147]: "tunnel7" #181: starting keying
> attempt 14 of an unlimited number
> Apr 15 09:24:29 vpnsrv1 pluto[9147]: "tunnel7" #190: initiating Quick
> Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #181 {using
> isakmp#188 msgid:bbc986f7 proposal=defaults
> pfsgroup=OAKLEY_GROUP_MODP2048}
> Apr 15 09:24:29 vpnsrv1 pluto[9147]: "tunnel1" #188: Informational
> Exchange message must be encrypted
>
> After a restart of both peers it does work again for a few minutes,
> but than the same issue happens again.
>
> Tunnel sample config, same simple setup on both peers.
>
> conn tunnel7
>         left=124.43.48.176
>         leftnexthop=69.115.176.1
>         leftsubnet=192.168.202.0/24
>         right=142.34.84.222
>         rightsubnet=192.168.1.0/24
>         rightnexthop=142.34.84.193
>         authby=secret
>         keylife=1h
>         auto=start
>
>
> Any ideas on this?
>
>
> Regards,
> Ted
>
>
>
>
>
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

FYI,

I am starting to suspect a corruption issue on the ISP side. Magically  
this issue stop with no intervention.

Unfortunately dummy me did not have his back door in place to be able  
to get packet capture on both end :-(

regards,
Ted

More information about the Users mailing list