Re: Questions regarding IPsec deployment

[Tom Rymes <trymes@rymes.com>]

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

Peter,

I think part of your issue is the Orange network. To be honest, I've never quite figured it out, and it has always given me trouble when I have tried to use it.

Having said that, I have multiple sites connected back to a central office, most with Blue and Green networks. There is no firewall magic required to allow traffic, traffic flows unless you specifically block it.

You are right that blocking one portion of a remote LAN is not easily accomplished. I'd say that defining multiple tunnels is the best plan if you need to do that. 

Tom

> On Jan 20, 2018, at 5:41 AM, Peter Müller <peter.mueller(a)link38.eu> wrote:
> 
> 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