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=3a4459746774ddaabdf6c854...).
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@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