From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tom Rymes <trymes@rymes.com>
To: development@lists.ipfire.org
Subject: Re: Questions regarding IPsec deployment
Date: Sat, 20 Jan 2018 08:37:44 -0500
Message-ID: <37C376E9-2CEE-4903-9822-09E904605D9C@rymes.com>
In-Reply-To: <20180120114048.6fdc05fe.peter.mueller@link38.eu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8712820680951596790=="
List-Id: <development.lists.ipfire.org>

--===============8712820680951596790==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Peter,

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

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

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

Tom

> On Jan 20, 2018, at 5:41 AM, Peter M=C3=BCller <peter.mueller(a)link38.eu> =
wrote:
>=20
> Hello,
>=20
> 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. :-)
>=20
> (a) IPsec with multiple networks announced causes source address mismatch=20
>=20
> 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:
>=20
> 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.
>=20
> 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?
>=20
> (b) differ between multiple networks announced via the same IPsec connection
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Am I missing something here? What is the best practise for this?
>=20
> In case it is really a bug, it is filed at: https://bugzilla.ipfire.org/sho=
w_bug.cgi?id=3D11559
>=20
> (c) using SubjectAlternativeName in IPsec certificates
>=20
> 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.
>=20
> Please refer to bug #11594 (https://bugzilla.ipfire.org/show_bug.cgi?id=3D1=
1594).
>=20
> Should we implement this as default setting or just require that
> value when creating new certificates?
>=20
>=20
> Thanks and best regards,
> Peter M=C3=BCller

--===============8712820680951596790==--