headers
Martin Lambev | 9 Jun 2012 10:58
Picon

Re: [Openswan dev] [Openswan Users] IP XFRM/Netkey/Stale Routes/%pass

Thank you Rick,
Your info is still useful to me!

OpenSwan Team are working on this issue,  hope to nail down this soon…

I'm really lost when it comes to programming. I can understand partly the code, but OpenSwan one is too complicated for me to dive in it. 

What I can provide is testing and log files….

I'm not directly affected by the issue right now but that bugs me and keep gnawing me all the time ( two weeks already ).

Best Regards,

Martin



On Jun 9, 2012, at 4:39 PM, Rick Olson wrote:

On 06/08/2012 12:17 PM, Martin Lambev wrote:
Hi Rick, 

I'm into the exact same problem as you describe in your openswan mailing list. 

Reference: 

My post:

[Openswan Users] ERROR: netlink XFRM_MSG_DELPOLICY response for flow eroute_connection delete included errno 2: No such file or directory

https://lists.openswan.org/pipermail/users/2012-June/021668.html , I'm not going to any tech details, but the main problem remains even in openswan 2.6.38 

Your post:

[Openswan Users] IP XFRM/Netkey/Stale Routes/%pass



#ip xfrm policy
src 50.50.50.10/32 dst 116.55.126.226/32 proto udp sport 1701 dport 55103 
dir out priority 2080 ptype main 
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16401 mode transport
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 4 priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 3 priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 4 priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 3 priority 0 ptype main 

The problem described by you match exactly the trouble that I have, I also try to dig it to the code and compare old vs. new versions 2.6.26 to 2.6.38 kernel_netlink.c file but because I do not understand C I'm lost….

tested with EPEL Openswan 2.6.32 - same issue… 

pluto try to delete the xfrm dir out policy but because there is not exact match ( I think it's client 'dport' is not there at all in the delete statement  ) that's why  it yells: "ERROR: netlink XFRM_MSG_DELPOLICY response for flow eroute_connection delete included errno 2: No such file or directory "

Especially " No such file or directory " shows up if  only if the policy that is left does not match completely. Examlpe could be applaied to the policy shown above:
If we try to delete it with this statement Missing is dport (clients port) # ip xfrm policy delete dir out src 50.50.50.10/32 dst 116.55.126.226/32 proto udp sport 1701
we get this error: RTNETLINK answers: No such file or directory

#ip xfrm policy
src 50.50.50.10/32 dst 116.55.126.226/32 proto udp sport 1701 dport 55103 
dir out priority 2080 ptype main 
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16401 mode transport
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 4 priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 3 priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 4 priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 3 priority 0 ptype main

but if we do: # ip xfrm policy delete dir out src 50.50.50.10/32 dst 116.55.126.226/32 proto udp sport 1701 dport 55103
we get no error and dir out policy is deleted, so I guess that dport either is missed in the pluto xfrm delete code ( which I could not locate clearly in kernel_netlink.c  if this is the correct file) 

ip xfrm policy
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 4 priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 3 priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 4 priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
dir 3 priority 0 ptype main 


So can you explain your "dirty hack" with _updown.netkey script? Where are you put this script and how you call it? Is this full script code?

Best Regards,

Martin


Hi Martin,

I feel your pain.  Unfortunately, it's been a really long time since I have been dealing with this issue, and I no longer maintain L2TP VPN setups (and haven't for at least a year now).  While my shell script hacks did work for me at the time, with the version I was running then, I unfortunately shot myself in the foot by not keeping track of which version I was using with the functional workaround.  Long story short, I applied several different patches supplied to me from the OpenSwan team, but ultimately was never able to get the XFRM policies to break down in a workable way again.  The method I describe with the shell scripts will _not_ work anymore.  The %pass bug was fixed in a patch quite a while ago, so that shouldn't be happening anymore.

In the end, I think wrote some lame cron job that looked for XFRM policies sitting around that did not have an associated connection established with netstat or something.  I don't have this anymore, and I don't remember exactly what I was doing... it was a last-ditch effort.

If you can locate any places where the connection is terminated, you might be able to cobble something together to manually break down the XFRM policy.  I don't know what OpenSwan officially suggests on this issue, maybe use their kernel module instead of netkey.

I still occasionally get emails from people over this problem, and I really wish I could be more help, but because there were conversations both on the mailing list and in IRC regarding this issue, the details are too scattered.

Good luck,

Rick

_______________________________________________
Dev mailing list
Dev <at> lists.openswan.org
https://lists.openswan.org/mailman/listinfo/dev
Permalink | Reply | 0 comments |
headers
Avesh Agarwal | 26 Jun 2012 23:36
Picon
Favicon

[Openswan dev] Patches for Openswan reserved fields and traffic selectors in transport issues


Hello,

I have prepared patches for following issues in Openswan:

1. IKEv2 reserved fields issues (redhat bz#831669): As per RFC 5996,
reserved fields must be ignored on receipt irrespective of their value.
In the current openswan implementation, some payloads such as tranform,
proposal, id, ke, vendor id, auth, suffer from the issue that the
contents of the reserved fields are not being ignored on receipt, and
infact Openswan outputs errors and negotiation fails. The attached patch
(openswan-831669.patch) addresses this issue and now Openswan ignores
the reserved fields and IKE negotiation succeeds even if reserved fields
are not zero.

2. Traffic selectors in transport mode (both ikev1/ikev2) (redhat
bz#831669): Openswan does not pass traffic selectors information to
kernel during setup of SAs when a connection is configured in transport
mode. This might lead to situation where esp packets not matching to
existing traffic selectors can pass through kernel when the SA is in
transport mode. The attached patch (openswan-831676.patch) addresses
this issue and now Openswan passes traffic selectors information to
kernel when SAs are setup in transport mode.

Any feedback on the patches is appreciated.

--

-- 
Thanks and Regards
Avesh
Attachment (openswan-831669.patch): text/x-diff, 3852 bytes
Attachment (openswan-831676.patch): text/x-diff, 4325 bytes
_______________________________________________
Dev mailing list
Dev <at> lists.openswan.org
https://lists.openswan.org/mailman/listinfo/dev
Permalink | Reply | 2 comments |
headers
Andreas Herz | 26 Jun 2012 11:49

[Openswan dev] Trying to bugfix klips issue with kernel 2.6.35 and newer

Hi,

i already reported that issue at the IRC channel and now want to patch
it with your help. With kernel 2.6.35 they introduced the function
skb_orphan_try() in net/core/dev.c that calls skb_orphan when the sk is
set and no tx_flags. This change resulted in the following bug with
openswan (tested with 2.6.36 and 2.6.38 release):

We use KLIPS and authentication by CA. The first problem was that the
packet with the certificate was bigger then 1400 and got fragmented. The
second part of the paket couldn't go through cause the source port was
not found.
At "klips_debug:ipsec_xmit_SAlookup:" the sport was = 0 instead of 500
and when i put more debug information into klips_debug i saw that the
skb->sk was never set and so the udphdr was used for the first part
to detect the sport but that didn't work for the second part of the
packet (udphdr is null).
One workaround was to set override_mtu to 1560 or higher to get the
packet through without fragmentation. Then there was a 30 second delay
between "STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG
cipher=aes_128 prf=oakley_sha group=modp2048}" and "initiating Quick
Mode RSASIG+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+SAREFTRACK to replace #50
{using isakmp#56 msgid:31cc42e0 proposal=defaults
pfsgroup=OAKLEY_GROUP_MODP2048}".

What i found out that the problem is that skb->sk is not set in
ipsec_tunnel.c when checked via "if(ixs->skb->sk)" in the
"ipsec_tunnel_SAlookup" function. The reason i found is the new function
skb_orphan_try that calls skb_orphan that flushes the skb->sk to NULL.
If i remove the skb_orphan_try function in net/core/dev.c everything is
working as expected.

What i'm asking now is, could you tell me if this is a kernel bug or
could it be fixed within openswan. The only solution to prevent the
skb_orphan_try function to execute skb_orphan is to set the tx_flags,
because the check is:

if (sk && !skb_shinfo(skb)->tx_flags)

And we need the sk so only setting skb_shinfo(skb)->tx_flags to some
value would help. Is this an option for openswan to set this flags at
some place?

Greetings

--

-- 
Andreas Herz
Permalink | Reply | 0 comments |

Gmane