[Openswan dev] [slanser at tallmaple.com: Re: [Openswan - Bug #1342] Pluto 30-second encrypted TCP connection stall with on-demand peering (NETKEY)]

[Steve Lanser]

It certianly sounds like the same issue.

I'll get to this after dealing with some of the higher priority IKEv2
issues.  This issue is a much lower priority for us since we largely aviod
the problem by configuring our connections with auto=start.  Packets issued
after a connection is brought up in this fashion are not subject to delay.

I have confirmed, however, that the behavior is still present in 2.6.38.

Steve

On Tue, Apr 10, 2012 at 03:50:32AM -0400, redmine at openswan.org wrote:
> 
> Issue #1342 has been updated by Tuomo Soini.
> 
> Target version changed from Openswan 2.x CVS (HEAD) to Openswan 2.6.39
> 
> Can you try the patch file bug1334.bug from bug #1334 if this is the same issue?
> ----------------------------------------
> Bug #1342: Pluto 30-second encrypted TCP connection stall with on-demand peering (NETKEY)
> https://www.openswan.org/issues/1342#change-2693
> 
> Author: Steve Lanser
> Status: New
> Priority: High
> Assignee: 
> Category: Pluto
> Target version: Openswan 2.6.39
> 
> 
> Create a valid connection on two hosts.  Add the connection on each host, but only ask pluto to "route" the connection on each end, so that it does not come up automatically, but will come up on demand due to the policy table (via an IPsec "acquire" event).
> 
> Then either ping or start an ssh connection from one host to the other.
> 
> Pluto receives the acquire message and brings up the peering right away, but the first packet that triggered the acquire is either dropped, or is delayed for about 30 seconds.
> 
> With both ping and with TCP, there is a 30 second delay between the time the connection is established and delivery of the 
> first encrypted packet from the initiator to the responder, as seen from tcp dump.
> 
> Interestingly, ping reports no packet loss:
> 
> 9 packets transmitted, 9 received, 0% packet loss, time 8003ms
> rtt min/avg/max/mdev = 0.193/0.255/0.321/0.041 ms
> 
> It almost seems like the packet is held in queue for 30 seconds-- it's not yet clear.
> 
> This issue is consistently reproducible on Openswan 2.6.32, and 2.6.38dr2 under NETKEY.
> 
> In contrast KAME's racoon under NETKEY does not have this delay.  Racoon delays for just over a second-- long enough for the first ping request to time out, and it does:
> 
> --- tb11.tallmaple.com ping statistics ---
> 2 packets transmitted, 1 received, 50% packet loss, time 1000ms
> rtt min/avg/max/mdev = 0.254/0.254/0.254/0.000 ms
> 
> But after ~1.1 seconds, the first encrypted packet (presumably a retransmitted ICMP echo request) is seen, and ping starts responding.  Similarly, with ssh there is a one second delay, then slogin connects, so under racoon there's not noticeable disruption.
> 
> Finally note that under pluto this delay can be "avoided" by aborting the first connection attempt and starting a new one, e.g. if you abort the first connection attempt with a CTRL-C and reissue it, the second one goes through immediately.
> 
> This is our bug ID 14441.
> 
> Test results are attached.  The initiating peer in each case was tb7 (10.2.0.27) and the receiving peer was tb11 (10.2.0.31).
> 
> slanser at tallmaple.com
> 
> 
> -- 
> You have received this notification because you have either subscribed to it, or are involved in it.
> 

----- End forwarded message -----