Questions regarding IPsec deployment

Questions regarding IPsec deployment

[Peter Müller]

[-- 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

Re: Questions regarding IPsec deployment

[Tom Rymes]

[-- 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

Re: Questions regarding IPsec deployment

[Peter Müller]

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

Hello Tom,

thanks for the answer.

> 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.
Actually, my setting is configured the other way rout: Every
traffic is blocked unless it is allowed by a firewall rule.
While this makes things more complicated sometimes, it tends
to be more effective against new attacks.
> 
> 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. 
Certainly this would work. What puzzles me is that at the
OpenVPN configuration page, you can specify several networks
belonging to one IPsec connection (it is in the "advanced
options" section for road warriors, this commit is related
to it: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=3a4459746774ddaabdf6c85414b7b91d75863740).

This is exactly what I was looking for at the firewall rules
page... :-) Does anybody know a technical dependence blocking
this?

By the way (I know this is not a support list, but the IPsec
documentation in the wiki is poor): Does anybody have
experience with IPsec roadwarrior connections here? I am
currently trying to bring up a connection between IPFire and
OpenBSD. After some crypto issues (groups like Curve25519
and Brainpool* don't work, using "modp4096" now), the IKE
connection is up, but ESP fails due to this error message(s):

14:52:42 charon:  15[IKE] sending DELETE for ESP CHILD_SA with SPI c94407b5 
14:52:42 charon:  15[IKE] failed to establish CHILD_SA, keeping IKE_SA 
14:52:42 charon:  15[IKE] no acceptable traffic selectors found 
14:52:42 charon:  15[IKE] maximum IKE_SA lifetime 10615s 
14:52:42 charon:  15[IKE] scheduling reauthentication in 10075s

I guess this is because I did not specify a remote IP of
the roadwarrior anywhere, but it did not became clear to
me where to do that in the WebUI.

Thanks in advance.

Best regards,
Peter Müller



> 
> 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