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