[Openswan dev] [Openswan Users] Ipsec configuration Lucent VPN Gateway with OpenSwan or others (Lucent IPSec Client 9.2.0 in Windows XP)

[Michael H. Warfield]

Paul, et al.

Ok...  Adding the dev at openswan.org list to this one at this point.

I've finally isolated the problem down with OpenSwan 2.6.23 and 2.6.24
failing to talk with the Cisco ASA 3000.  Symptoms are the connection
comes up but we can't ping across the tunnel and there are no tunnel
related addresses or routes in the tables.  Debugging "_updown.netkey"
revealed that it was failing to add the addresses and routes with "ip
addr replace" and "ip route replace" both returning "RTNETLINK:
Operation not permitted".  Disabling selinux didn't help so I went
hunting down anything to do with capabilities and found that there had
been some changes in 2.6.23 to do with LIBCAP_NG.  Found that Fedora has
"%define USE_LIBCAP_NG 1" in the spec file for building the rpms.
Changed that to "%define USE_LIBCAP_NG 0" and rebuild and it now works.
So something appears to be broken in dropping capabilities in pluto at
this time.  Code looked right to me but it's definitely no workie and
making that change to not do that fixed the problem I was seeing where
2.6.22 worked on Ubuntu and 2.6.23/4 failed on Fedora.

On Wed, 2010-02-24 at 22:11 -0500, Michael H. Warfield wrote: 
> On Wed, 2010-02-24 at 14:09 -0500, Michael H. Warfield wrote: 
> > On Tue, 2010-02-23 at 23:00 -0500, Paul Wouters wrote: 
> > > On Tue, 23 Feb 2010, Michael H. Warfield wrote:
> > > 
> > > >> (btw. this discussion could be done on dev@? It's nice for other people to
> > > >>   see the efforts being done more visibly)
> > > >
> > > > Oh DAMN IT man!  I am NOT on that list.  I didn't even know about it.
> > > > Ok, that's probably my fault for not digging deeper.  I'll sign up very
> > > > shortly.  (Rhetoractly - how the HELL did I miss that...).
> > 
> > Oh...  Actually I am on that list after all.  It's just that I had both
> > lists routed into a single mailbox and didn't realize it.  Duh.  Never
> > mind me.
> > 
> > > Ahhh. Can I forward my latest reply to you to there? It might provide some
> > > useful hooks.
> > 
> > > Some developers are not on users@ and only on dev at . Some are not paying too
> > > much attention to users@ due to the extra newby noise.
> > 
> > > Paul
> > 
> > ITMT...  I've run into a couple more problems.  The problem with the
> > no-proposals chosen turned out to be the proposal after all and maybe
> > some quirk in the Cisco.  Vpnc sends it 24 proposals and it selects
> > aes128-sha1-mod1024.  But, when OpenSwan sends that one single policy,
> > it doesn't like it for some weird reason.  When I tried
> > aes256-sha1-mod1024, it liked it just fine and I got past that point.
> > Also turns out that the concentrator doesn't care about that key type id
> > after all so @FooBar works just as well as @[FooBar although the later
> > is more formally correct.  That protocol / port stuff was also not an
> > issue.
> > 
> > Now it seems to be going through all the negotiations but the tunnel
> > can't be pinged when its done and I think I see why.  The SA's that are
> > being set in the policy are referencing a local IP address that's been
> > given to me by the concentrator.  But, because this is Netkey, not
> > KLIPS, that address is never assigned to an interface and no routes are
> > added to the routing table.  So the kernel is sourcing a packet from my
> > local real IPv4 address which, in turn, never trips the SA's because the
> > src doesn't match.  Not sure how to fix that one.  Maybe by plugging in
> > a couple of extra SA's by hand at first, I guess.  That still might now
> > work, though, if the other side is only accepting from that local
> > assigned address.
> 
> Ok...  Getting to the bottom of this one and it has me concerned.
> Problem seems to be that ipsec is not able to set the routes or add
> interface information.  I stuffed a "set -x" in _updown.netkey and
> redirected stderr into a log file and got some of this: 
> 
> + it='ip addr add 9.12.226.247/32 dev eth0'
> ++ eval ip addr add 9.12.226.247/32 dev eth0
> + oops='+++ ip addr add 9.12.226.247/32 dev eth0
> RTNETLINK answers: Operation not permitted'
> + st=2
> + '[' ' +++ ip addr add 9.12.226.247/32 dev eth0
> RTNETLINK answers: Operation not permitted' = ' ' -a ' 2' '!=' ' 0' ']'
> + case "$oops" in
> + '[' ' +++ ip addr add 9.12.226.247/32 dev eth0
> RTNETLINK answers: Operation not permitted' '!=' ' ' -o ' 2' '!=' ' 0' ']'
> + echo '/usr/libexec/ipsec/_updown.netkey.sh: addsource `ip addr add 9.12.226.247/32 dev eth0'\'' failed (+++ ip addr add 9.12.226.247/32 dev eth0
> RTNETLINK answers: Operation not permitted)'
> /usr/libexec/ipsec/_updown.netkey.sh: addsource `ip addr add 9.12.226.247/32 dev eth0' failed (+++ ip addr add 9.12.226.247/32 dev eth0
> RTNETLINK answers: Operation not permitted)
> + return 2
> 
> This is with both OpenSwan 2.6.23 and 2.6.24 on Fedora 12.  The former
> is a stock build with FIPS and NSS from the repos.  The later is my own
> build without.  On another machine, OpenSwan 2.6.22 on Ubuntu works like
> a charm.  I have turned selinux to permissive mode.
> 
> Running the commands had succeed.
> 
> Is this a Fedora problem or an OpenSwan problem?  If it's an OpenSwan
> problem, I guess I can take it to the OpenSwan -dev list.
> 
> > On other little buglet for you.  It's not removing all the SA's in the
> > policy database when you down a connection.  It's removing 2 of the
> > three it adds.  Not a major problem but it will accumulate dangling SA's
> > if the connection is raised and lowered and raised and lowered.
> 
> > Mike
> 
> Mike

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/dev/attachments/20100225/8988ce66/attachment.bin