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

[Rick Olson]

Hello,

I run an openswan VPN server setup as a standard roadwarrior connection,
using netkey.  I have issues with the XFRM policies generated from
pluto, which I've had to resort to managing "manually" in the _scariest_
possible way via the _updown.netkey shell script.

There is actually a core bug here, which I am not awesome enough to
figure out a solution for, in spite of my best efforts.  

The most relevant mail-posting I've found is initiated from Bob Miller,
at http://readlist.com/lists/openswan.org/users/2/10805.html
with a response from Tuomo Soini at:
http://readlist.com/lists/openswan.org/users/2/10815.html

The first lead-on to this issue happened with the following in ipsec
auto --status output ending in: 

000 xx.xx.xx.xx/32:0 -0-> yy.yy.yy.yy/32:0 => %pass 0    no routed
template covers this pair

This was caused by OSX clients connecting and creating a ip xfrm policy
that was what I consider a "blanket" policy, breaking the entire state
of ipsec until the policy was explicitly deleted (manually) or until
ipsec was restarted (causing that policy to be deleted implicitly).  [it
was 'bleve' in IRC that pointed out the %pass bug problem to me]

So I dug into openswan source code, and I dug, and I found
programs/pluto/kernel_netlink.c which is what appears to be
creating/managing the XFRM policies, and I hacked the code; but I did
not prevail.  But evidently, I'm in completely the wrong place anyway,
so maybe it's better I was not successful.

So like I said at the beginning of the email, I'm managing xfrm policies
in the _scariest_ possible way via the _updown.netkey script via the
following abomination in "doroute()" (recently removed in commit
f982116e3048661b1cfc1c9837e6c3481b2dcc5d, but regardless my problem
remains even in current HEAD):

doroute() {
    if [ "$1" = "del" -o "$1" = "replace" ]; then
        #OSX FIX
        ip xfrm policy show | egrep '^src(.*)dst(.*)proto udp $' | xargs
ip xfrm policy delete dir out
        # Guess OSX FIX wasn't that great, Windows too now
        if [ "$1" = "del" ]; then
                ip xfrm policy show | grep "${PLUTO_PEER}" | xargs ip
xfrm policy delete dir out
        fi
    fi
    [............]
}


While I currently have this creepy hack in place, I'm wondering how I
should go about filing a proper bug report for this issue, or if someone
who knows more about this problem might be able to file one in the
correct space.

Cheers,

Rick
(yun on IRC, I pop in every once in a while :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20100911/55dedf39/attachment.bin