[Openswan dev] Openswan 2.6.24 TCP traffic

Tue Feb 9 08:43:23 EST 2010

Thanks for your reply.
Did someone try doing ftp put on some machine using kernel 2.6.32 and Openswan 2.6.24?

I also tried using kernel 2.6.31 and it still fails, any idea on which version should it work?

Regards
Ronen Shitrit

-----Original Message-----
From: David McCullough [mailto:david_mccullough at mcafee.com] 
Sent: Tuesday, February 09, 2010 2:10 PM
To: Ronen Shitrit
Cc: dev at openswan.org
Subject: Re: [Openswan dev] Openswan 2.6.24 TCP traffic

Jivin Ronen Shitrit lays it down ...
> 
> Sorry if it mail was sent more then once, but I keep getting:
> "Due to too much spam, the developer list has been closed for posting for non-members. Please subscribe to the list and then repost your message."
> 
> Hi
> 
> I'm working on latest Openswan release 2.6.24 with kernel 2.6.32 and I can't get ftp to work over an IPsec connection.
> 
> I ramp up a connection in front of windows PC and I can ping the PC just fine, capturing the packets shows the connection was properly established.
> When I try to ftp put a large file I get a recursive message of the following error:
> klips_error:ipsec_xmit_send: ip_send() failed, err=90
> 
> I enabled the openswan debug (see log below) and found that the IPsec receive an 1500 bytes packet size with DF set in the packet,
> The openswan detect it and try to send an ICMP indicating packet size of 1500 can't be sent (ipsec_xmit line 1741), however the icmp_send fails since skb_dst(skb) is NULL. 
> Tracing the SKB to the beginning of the Openswan, I can see that ipsec_tunnel_start_xmit is being called with skb_dst(skb) set to NULL.
> 
> When checking the same path on working setup using openswan 2.4.9 with kernel 2.6.22, I see that skb->dst is properly initialized when calling ipsec_tunnel_start_xmit.
> 
> I'm wondering if the problem is the fact that skb_dst(skb) is initialized to NULL when calling ipsec_tunnel_start_xmit, or this is part of the changes done by the kernel on latest versions and the Openswan should be adjusted.

Almost certainly kernel changes.  There have been a few but I haven't met
this one yet.

Not sure how to get dst set other than doing the routing,  but that seems
excessive in this case.  Perhaps someone else has some ideas ?

Cheers,
Davidm

> ipsec_tunnel_start_xmit: STARTING
> klips_debug:ipsec_xmit_strip_hard_header: >>> skb->len=1500 hard_header_len:14 45:08:05:dc:bc:02:40:00:40:06:00:74:0a:04 
> klips_debug:   IP: ihl:20 ver:4 tos:8 tlen:1500 id:48130 DF frag_off:0 ttl:64 proto:6 (TCP) chk:116 saddr:10.4.50.135:35637 daddr:10.4.50.15:3139
> klips_debug:ipsec_xmit_strip_hard_header: Original head,tailroom: 196,0
> klips_debug:ipsec_findroute: 10.4.50.135:35637->10.4.50.15:3139 6
> klips_debug:rj_match: * See if we match exactly as a host destination
> klips_debug:rj_match: ** try to match a leaf, t=0pdfaec100
> klips_debug:ipsec_xmit_SAlookup: checking for local udp/500 IKE packet saddr=a043287, er=0pdfaec100, daddr=a04320f, er_dst=a04320f, proto=6 sport=35637 dpor9
> ipsec_sa_getbyid: linked entry in ipsec_sa table for hash=24 of SA:esp.21010568 at 10.4.50.15 requested.
> ipsec_sa_get: ipsec_sa dd41c800 SA:esp.21010568 at 10.4.50.15, ref:1 reference count (3++) incremented by ipsec_sa_getbyid:566.
> klips_debug:ipsec_xmit_init2: found ipsec_sa -- SA:<ESP_3DES_HMAC_SHA1> esp.21010568 at 10.4.50.15
> klips_debug:ipsec_xmit_init2: calling room for <ESP_3DES_HMAC_SHA1>, SA:esp.21010568 at 10.4.50.15
> klips_debug:ipsec_xmit_init2: Required head,tailroom: 16,20
> klips_debug:ipsec_xmit_init2: existing head,tailroom: 196,0 before applying xforms with head,tailroom: 16,20 .
> klips_debug:ipsec_xmit_init2: mtu:1500 physmtu:1500 tothr:16 tottr:20 mtudiff:36 ippkttotlen:1500
> klips_info:ipsec_xmit_init2: dev ipsec0 mtu of 1500 decreased by 37 to 1463
> klips_debug:ipsec_xmit_init2: fragmentation needed and DF set; sending ICMP and passing packet
> klips_debug:ipsec_xmit_init2: hard header already stripped.
> klips_debug:ipsec_xmit_init2: head,tailroom: 48,20 after allocation
> klips_debug:   IP: ihl:20 ver:4 tos:8 tlen:1500 id:48130 DF frag_off:0 ttl:64 proto:6 (TCP) chk:116 saddr:10.4.50.135:35637 daddr:10.4.50.15:3139
> klips_debug:ipsec_xmit_encap_once: calling output for <ESP_3DES_HMAC_SHA1>, SA:esp.21010568 at 10.4.50.15
> klips_debug:ipsec_xmit_encap_once: pushing 16 bytes, putting 20, proto 50.
> klips_debug:ipsec_xmit_encap_once: head,tailroom: 32,0 before xform.
> klips_debug:ipsec_alg_esp_encrypt: entering with encalg=3, ixt_e=bf051e5c
> klips_debug:ipsec_alg_esp_encrypt: calling cbc_encrypt encalg=3 ips_key_e=de446200 idat=dfa30044 ilen=1488 iv=dfa3003c, encrypt=1
> klips_debug:ipsec_alg_esp_encrypt: returned ret=1
> klips_debug:ipsec_xmit_encap_once: after <ESP_3DES_HMAC_SHA1>, SA:esp.21010568 at 10.4.50.15:
> klips_debug:   IP: ihl:20 ver:4 tos:8 tlen:1536 id:48130 DF frag_off:0 ttl:64 proto:50 (ESP) chk:36 saddr:10.4.50.135 daddr:10.4.50.15
> ipsec_sa_put: ipsec_sa dd41c800 SA:esp.21010568 at 10.4.50.15, ref:1 reference count (4--) decremented by ipsec_xmit_cont:1102.
> klips_debug:ipsec_findroute: 10.4.50.135:0->10.4.50.15:0 50
> klips_debug:rj_match: * See if we match exactly as a host destination
> klips_debug:rj_match: ** try to match a leaf, t=0pdfaec100
> klips_debug:ipsec_xmit_restore_hard_header: After recursive xforms -- head,tailroom: 32,0
> klips_debug:ipsec_xmit_restore_hard_header: With hard_header, final head,tailroom: 32,0
> klips_debug:ipsec_xmit_send: ...done, calling ip_send() on device:eth0
> klips_debug:   IP: ihl:20 ver:4 tos:8 tlen:1536 id:48130 DF frag_off:0 ttl:64 proto:50 (ESP) chk:36 saddr:10.4.50.135 daddr:10.4.50.15
> klips_error:ipsec_xmit_send: ip_send() failed, err=90
> 
> 
> 
> Regards
> Ronen Shitrit
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
> 
> 

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org