[strongSwan] Output hangs, eventually completes

[John Emerson]

Martin,
Thanks for your previous response, and sorry for my email that preceded this that I seen by accident too soon.

I set the connection with 'esp=null-sha1!’ on both client and server side. Then ran tcpdump on both sides.

I experienced a hang at 21:23:37. 

There was nothing in the syslog at that time of interest:
Oct 28 21:22:59 ip-10-0-16-8 charon: 10[NET] sending packet: from 10.0.16.8[4500] to AA.AAA.AA.A[20274]
Oct 28 21:23:10 ip-10-0-16-8 charon: 11[IKE] sending keep alive to AA.AAA.AA.A[52010]
Oct 28 21:23:10 ip-10-0-16-8 charon: 10[NET] sending packet: from 10.0.16.8[4500] to AA.AAA.AA.A[52010]
Oct 28 21:23:19 ip-10-0-16-8 charon: 06[IKE] sending keep alive to AA.AAA.AA.A[20274]
Oct 28 21:23:19 ip-10-0-16-8 charon: 10[NET] sending packet: from 10.0.16.8[4500] to AA.AAA.AA.A[20274]
Oct 28 21:23:30 ip-10-0-16-8 charon: 16[IKE] sending keep alive to AA.AAA.AA.A[52010]
Oct 28 21:23:30 ip-10-0-16-8 charon: 10[NET] sending packet: from 10.0.16.8[4500] to AA.AAA.AA.A[52010]
Oct 28 21:23:39 ip-10-0-16-8 charon: 04[IKE] sending keep alive to AA.AAA.AA.A[20274]
Oct 28 21:23:39 ip-10-0-16-8 charon: 10[NET] sending packet: from 10.0.16.8[4500] to AA.AAA.AA.A[20274]
Oct 28 21:23:50 ip-10-0-16-8 charon: 03[IKE] sending keep alive to AA.AAA.AA.A[52010]
Oct 28 21:23:50 ip-10-0-16-8 charon: 10[NET] sending packet: from 10.0.16.8[4500] to AA.AAA.AA.A[52010]
Oct 28 21:24:10 ip-10-0-16-8 charon: 12[IKE] sending keep alive to AA.AAA.AA.A[52010]
Oct 28 21:24:10 ip-10-0-16-8 charon: 10[NET] sending packet: from 10.0.16.8[4500] to AA.AAA.AA.A[52010]

The two tcpdump files attached. I’d appreciate any help.

Thank you,
John



> On Oct 23, 2014, at 12:37 AM, Martin Willi <martin at strongswan.org> wrote:
> 
> John,
> 
>> Unfortunately, the logs don’t seem to provide much help. At 16:44:43, I
>> executed ‘ps -ef’ on the server. It’s now 17:06:41 and I still don’t
>> see all the output.
> 
> At this time there is actually nothing happening at the IKE level, hence
> I've my doubts that it is actually related to the IKE daemon.
> 
> Most likely some packet loss is involved for your TCP stream somewhere
> on your link. Interesting would be to find where packets get dropped
> (during encapsulation, decapsulation or somewhere in-between, and in
> which direction). Attaching a packet sniffer on both ends could help to
> analyze what exactly is happening; using null-encryption for testing
> could help to see your TCP streams.
> 
> Regards
> Martin
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141029/3d45113b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server
Type: application/octet-stream
Size: 117162 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141029/3d45113b/attachment-0002.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141029/3d45113b/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client
Type: application/octet-stream
Size: 216430 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141029/3d45113b/attachment-0003.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141029/3d45113b/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1821 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141029/3d45113b/attachment-0001.bin>