Bug 11559

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. :-)

- ping -

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.

Alex, could you have a look at this? Thank you.

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

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?

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.

Alex: I don't want to appear utterly rude, but in case you need more information, I am willing to answer... :-)

For the record: Alex built a solution to fix this, I will test and report.

https://patchwork.ipfire.org/patch/1735/

https://patchwork.ipfire.org/project/ipfire/list/?series=301

This is staged by now and will be fixed in upcoming C121.

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