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

[Rick Olson]

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/users/attachments/20120609/4919ccc3/attachment.html>