[strongSwan] several questions and problems ;)

Sun Oct 3 21:31:55 CEST 2010

Hi Andreas.

On Sun, 2010-10-03 at 13:11 +0200, Andreas Steffen wrote:
> > 1) Does this sound reasonable for my setup from above, or have I made any
> > stupid mistakes? Or bad decisions regarding security.

> I recommend to use the '!' strict flag in the ike= and esp= cipher suite
> definitions, thus restricting both the proposed and accepted algorithms
> to those explicitly listed in the ike= and esp= statements.
Ah,.. I've already read this somewhere and wanted to do this, but then
forgot about it.
It's missing in the manpage however, perhaps you can add it :)

> > 3) Both hosts have auto = start... it seems now, that two connections are
> > established then:
...
> > Why?
> IKEv2 allows multiple concurrent IKE and IPsec SAs. If you want
> only one IKE SA then I recommend to use auto=start on one side
> and auto=add on the other side.
Ah I see... is there any benefit of having two? Or does it just waste
performance?

I mean each one of them works in both directions, right? So how is one
chose if there are two?

If I set one side to auto=add, it should have no effect on (2) (the
always being established thingy) because the one side which has
auto=start left takes care of this anyway, right?

If I'd set one side to auto=start, and the other to auto=route, I'd
still end up with _two_ connections as soon as traffic occurs right?

> > Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'test-vectors' failed to
> > load: /usr/lib/ipsec/plugins/libstrongswan-test-vectors.so: cannot open
> > shared object file: No such file or directory
> > Oct  3 02:09:17 hilbert charon: 00[LIB] plugin 'revocation' failed to
> > load: /usr/lib/ipsec/plugins/libstrongswan-revocation.so: cannot open
> > shared object file: No such file or directory
Guess I should at least report these to the Debian guys as it seems
they're just missing,.. is revocation for CRL support?

> > Oct  3 02:09:17 hilbert charon: 00[KNL] listening on interfaces:
> > Oct  3 02:09:17 hilbert charon: 00[KNL]   eth0
> > Oct  3 02:09:17 hilbert charon: 00[KNL]     84.16.235.61
> > Oct  3 02:09:17 hilbert charon: 00[KNL]     84.16.242.145
> > Oct  3 02:09:17 hilbert charon: 00[KNL]     84.16.226.65
> > Oct  3 02:09:17 hilbert charon: 00[KNL]     84.16.242.146
> > Oct  3 02:09:17 hilbert charon: 00[KNL]     fe80::80a7:3aff:fe36:3827
btw: Can I configure on which interfaces (IP4/6) strongswan listens?

> The Debian package enables a lot of plugins that are not properly
> initialized. Therefore the loading fails and all these error messages
> appear in the strongSwan log. This looks rather ugly but does not do
> any actual harm, except if you actually want to use some of these
> plugins (e.g. attr-sql for SQL-based virtual IP pools).
Ok,.. I've already suspected this (and no I don't think that I want to
use any of these).
I guess it's better to life with those warnings than manually setting
load= to just the plugins I use, right?

Nevertheless, can't the code be changed to just load the plugins
(dynamically) when they're configured to be used?

> > =>  Why does it say "(EAP_ONLY)" I thought I'd do only authentication based
> > on certificate?
> >
> The EAP_ONLY notify message just advertises the potential capability to
> support the RFC 5998 EAP-only protocol.
Ah I see, thx :)

> > =>  Do these NAT* messages mean, that the NAT-case was detected (which
> > should not be the case I guess?
> >
> No, these NAT messages are IP address hashes used to detect
> NAT situations. They are always sent by default.
Is there a way to (easily) see when NATed mode has been selected? Just
want to go sure that it's not used because AFAIU it should not be
necessary in my setup.

> Which Linux kernel are you using? SHA_256_128, SHA_384_192 and
> SHA_512_256 were introduced with the 2.6.33 kernel. Earlier kernels only
> support a non-standard SHA_256_96 integrity algorithm.
Ah... clear.... that one was .32 :)

> > =>  Guess the connection is now established, isn't it?
> >
> No, the CHILD_SA was not established.
Ok that's strange,...
These error messages from above appeared only one one of the hosts (that
one where I did _not_ do "ipsec start"). The other host at least has a
line in the log which tells:
... establishing CHILD_SA hostB.example.org

And pinging the other host works from each of the two...
Why?

> > 5) What's the best way to solve this:
> > hostA and hostB each have multiple (actually 4) IP addresses, and I want
> > to configure secured connections between all possible cominations of them?
> >
> >
> > 6) AFAIU with the in kernel IPsec stack, there are no virtual interfaces
> > or manual routes beeing added, right? At least my
> > 84.16.235.0/24 dev eth0  proto kernel  scope link  src 84.16.235.61
> > 84.16.226.0/24 dev eth0  proto kernel  scope link  src 84.16.226.65
> > 84.16.242.0/24 dev eth0  proto kernel  scope link  src 84.16.242.145
> > default via 84.16.235.1 dev eth0
> >
> With IPsec you can have only one active IPsec tunnel between two hosts.
> The RFC 4555 MOBIKE protocol will automatically switch to another
> interface pair if the active connection goes down.
Uhm... well but these are all just other addresses used on the same NIC, having only one link.
What would happen now, if e.g. I have:
hostA:
1.0.0.1
1.0.0.2
1.0.0.3

hostB:
2.0.0.1
2.0.0.2
2.0.0.3

And I have set up IPsec between 1.0.0.1 and 2.0.0.1... and then some
services uses a different source and/or destination address.
Would this be still encrypted/authenticated or would it just go out
"normal"?

> > 7) With this setup, is it already guaranteed that e.g. if hostB's
> > strongswan crashes, hostA never sends unsecured packages to hostB? I mean
> > because hostA then tries to re-establish that connection (which might not
> > work however) but then, no packages are sent?
> >
> The strongSwan daemon is not supposed to crash.
Ok that was a bit unpolite ;) I meant generally "when it's not running".
This can be so much, me being stupid and stopping it, Debian's
init-system being upgraded/broken and not starting it at reboot, etc.
etc.

>  And even if it does, the
> IPsec policies will still exist.
Uhm... I guess I have no idea about that policies,... is there some
description about them?

> In order to make sure that no
> unencrypted packets leave the host you can define a default block policy
> using the ip xfrm policy add command.
Uhm how would that work?

Anyway,.. I guess I'd prefer an iptbles solution,... but I'll make an
additional post about that, once I've tried a bit more around.

Thanks,
Chris :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5677 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20101003/c51f7878/attachment.bin>