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

[Martin Lambev]

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
>> 
>> https://lists.openswan.org/pipermail/users/2010-September/019322.html
>> 
>> 
>> #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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openswan.org/pipermail/dev/attachments/20120609/1a10aee7/attachment.html>