Bug 11559

Summary: firewall: differ between multiple subnets within same IPsec connection
Product: IPFire Reporter: Peter Müller <peter.mueller>
Component: ---Assignee: Alexander Marx <alexander.marx>
Status: CLOSED FIXED QA Contact:
Severity: Major Usability    
Priority: Will affect an average number of users CC: michael.tremer, tomvend
Version: 2Keywords: NewFeature
Hardware: all   
OS: All   
See Also: https://bugzilla.ipfire.org/show_bug.cgi?id=10929
https://bugzilla.ipfire.org/show_bug.cgi?id=11624
https://bugzilla.ipfire.org/show_bug.cgi?id=11688
Bug Depends on:    
Bug Blocks: 11618    
Attachments: Screenshot of multiple IPsec subnets in OpenVPN connection options

Description Peter Müller 2017-12-06 17:33:59 UTC
The firewall engine is unable to differ between multiple subnets which are routed through the same IPsec connection.

For example, if the remote subnets also contain untrusted networks (DMZ!), a firewall rule can be only applied to none or all of these. Introducing an option to differ "IPsec connection XYZ|Subnet 192.168.2.0/24" would be very usable.
Comment 1 Peter Müller 2018-01-07 21:52:39 UTC
Created attachment 551 [details]
Screenshot of multiple IPsec subnets in OpenVPN connection options

In Core Update 117, a similar feature is implemented in OpenVPN connection setup.

Just for the records. :-)
Comment 2 Peter Müller 2018-02-06 19:19:21 UTC
- ping -
Comment 3 Peter Müller 2018-02-11 13:34:23 UTC
The impact of this issue seems to be much bigger than expected in first place:

              |----------|                          |---------|
[GREEN NET 1] |          |                          |         | [GREEN NET 2]
              | IPFire 1 |           ???            | IPFire2 |
[ORANGE NET 1]|          |                          |         | [ORANGE NET 2]
              |----------|                          |---------|

In this case, connections should be possible
- from GREEN 1 to GREEN 2,
- from ORANGE 1 to ORANGE 2,
- from GREEN 1 to ORANGE 2 and
- from GREEN 2 to ORANGE 1.

Current state:
Simply setting up _one_ IPsec connection does not work: The firewall engine does not provide the ability to allow or deny traffic from one remote network announced via an IPsec connection.

Workaround: Create multiple IPsec connections (as suggested by Michael):
This works, but causes more problems than it solves:
- Maintaining firewall rules for the different connections is a nightmare (own experience!).
- IPFire chooses the wrong interface as a packet source (see #11624) which causes additional trouble.

What makes this bug so annoying is the fact that you cannot create networks used by an IPsec manually (say the remote ORANGE one, for example), so there is no way of applying firewall rules to one specific IPsec network.
Comment 4 Peter Müller 2018-03-25 17:43:54 UTC
Alex, could you have a look at this? Thank you.
Comment 5 Alexander Marx 2018-04-05 19:02:58 UTC
Well, IPSec is NOT OpenVPN. In OpenVPN there are configuration  options for pushing routes. This is exactly what i implemented in the OpenVPN setup page.

I read something about IPSec but so far the common answer seems to be: It won't work.
Actually you can only create Routes on the client side (Roadwarrior).

Maybe i am wrong but it seems not possible by now.
If someone has other informations or can give hint how to push routes to the client in roadwarrior and Net-to-Net config i would appreciate your comments.

Best, 
Alex
Comment 6 Tom Rymes 2018-04-05 19:30:35 UTC
Wait, there seems to be some confusion here. Correct me if I am wrong, but this doesn’t have anything to do with pushing routes, unless there’s some magic going on in the background. The far side of a net to net IPSec tunnel defines its own routes, there is. I need to push anything. This is about being able to define multiple subnets for an IPSec tunnel, and then apply firewall rules to those subnets individually.

Setting up an IPSec tunnel with multiple subnet definitions already works, we use this feature extensively. The only difference between my set up and Peter’s, I’d memory serves, is that his firewall is set to block unless pecificalky allowed and mine is set to allow unless specifically denied.

It sounds to me that there are a few issues here:

1.) If I create an IPSec tunnel “MyTunnel” with two subnets defined, 10.1.0.0/24 and 192.168.0.0/24, there is only one option in the firewall interface for that tunnel. This means that I cannot block certain traffic going to 192.168.0.0/24, while allowing that traffic to 10.1.0.0/24. I am only able to allow all traffic to both subnets or deny all traffic to both subnets.

2.) For traffic to flow in Peter’s setup, he needs to specifically allow traffic with a firewall rule, and from his second post, it sounds like that isn’t working.

Peter, does that sum things up accurately? Also, are you able to make it work by manually specifying the subnet(s) in the source/destination fields, or does that not work for IPSec?
Comment 7 Peter Müller 2018-04-09 19:34:33 UTC
Hello Tom,

thanks, that sums it up perfectly.

I am unable to set up a network used by the IPSec N2N connection in the firewall rule, since it says "the network already belongs to a VPN connection". Basically, this is correct, but as mentioned, there is no way to define firewall more precisely than a whole IPsec connection.

As far as I am concerned, this has nothing to do with routing. It just needs an option in the firewall GUI to specify which networks announced via an IPsec tunnel a rule should apply to.
Comment 8 Peter Müller 2018-04-23 19:47:40 UTC
Alex: I don't want to appear utterly rude, but in case you need more information, I am willing to answer... :-)
Comment 9 Peter Müller 2018-04-26 17:33:31 UTC
For the record: Alex built a solution to fix this, I will test and report.
Comment 10 Peter Müller 2018-04-30 19:40:22 UTC
https://patchwork.ipfire.org/patch/1735/
Comment 12 Peter Müller 2018-06-18 18:42:20 UTC
This is staged by now and will be fixed in upcoming C121.
Comment 13 Peter Müller 2018-08-06 22:35:39 UTC
Core Update 122 has been released, this is fixed.

Thanks again for developing this feature.

https://www.ipfire.org/news/ipfire-2-21-core-update-122-released