Questions regarding IPsec deployment

["Peter Müller" <peter.mueller@link38.eu>]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

Hello,

I am currently experiencing several issues trying to
deploy IPsec. Since I am not sure weather hey are real
bugs, or just mistakes of mine, or questions left
because of missing documentation, I'll ask here. :-)

(a) IPsec with multiple networks announced causes source address mismatch 
 
In case an IPsec connection is set up between two IPFire
machines, with two networks (i.e. GREEN and ORANGE) announced
at each side, the source address of a remote firewall is
sometimes changing:

In my scenario, there is a firewall rule set up allowing
traffic from the GREEN IP of the remote firewall to a
local server. However, traffic is blocked because the
ORANGE IP of the remote firewall appears as the source address.

Technically, this is correct since both networks - GREEN and
ORANGE - are announced via the IPsec connection (/24 each).
Thereof, I do not consider this being a bug, or is it?

(b) differ between multiple networks announced via the same IPsec connection

A firewall rule may use an IPsec connection as source or destination.
In case multiple networks are announced over this connection,
such as described above, the rule will match against all of them.

But how do you differ between multiple networks? Say, you want
to allow traffic coming from the remote GREEN network, but not
from the remote ORANGE one.

I currently see two possibilities:
(i) Set up an IPsec tunnel for every (remote) network type: One
for GREEN networks only, one for ORANGE ones... Might cause some
network overhead, but well.
(ii) Set up custom networks at "firewall groups|networks" for each
of the IPsec networks announced. However, this fails because the
networks are already in use - which is technically correct again.

Am I missing something here? What is the best practise for this?

In case it is really a bug, it is filed at: https://bugzilla.ipfire.org/show_bug.cgi?id=11559

(c) using SubjectAlternativeName in IPsec certificates

Some IPsec programs (such as "iked" on OpenBSD) seem to ignore
the "Common Name" (CN) field of certificates and use SubjectAlternativeName
instead. I've read something similar for HTTP certificates, and
according to RFC 3280, SubjectAlternativeName must be used always.

Please refer to bug #11594 (https://bugzilla.ipfire.org/show_bug.cgi?id=11594).

Should we implement this as default setting or just require that
value when creating new certificates?


Thanks and best regards,
Peter Müller