Project

General

Profile

Actions
Copy link

Feature #16438

open

IPSEC VPN - support VTI tunnel to other firewall that doesn't do selector narrowing

Added by Lisandro Massera 8 months ago. Updated 15 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default

Description

Currently, whenever you try to create a vti IPSEC tunnel to another firewall pfSense automatically and forcefully adds 0.0.0.0/0; ::/0 to the traffic selector proposals, both local and remote.
This creates issues with firewalls that don't support selector narrowing or expect and exactly coincident phase 2 selector, like cisco firepower in policy based mode.
I have been in situations were I cannot start the tunnel because the other side rejects my proposal, but the other side can start the tunnel because pfSense/strongswan supports narrowing.

This all could be fixed by adding a checkbox to the phase 2 definition with the function "Don't add 0.0.0.0/0; ::/0 to the proposals". If this checkbox is left blank by default then it wouldn't affect existing behaviour and would allow the VPN connection to be made.

I have tested this by doing the following modification:

diff --git a/src/etc/inc/ipsec.inc b/src/etc/inc/ipsec.inc
index ba66ff9195..9f5c106ff8 100644
--- a/src/etc/inc/ipsec.inc
+++ b/src/etc/inc/ipsec.inc
@@ -2361,8 +2361,8 @@ function ipsec_setup_vtireq(& $child, & $ipsec_vti_cleanup_ifs, $p1, $reqid = 0)
        }
        /* This interface will be a valid IPsec interface, so remove it from the cleanup list. */
        $ipsec_vti_cleanup_ifs = array_diff($ipsec_vti_cleanup_ifs, array(ipsec_get_ifname($p1, $reqid)));
-       $child['local_ts'] .= ",0.0.0.0/0,::/0";
-       $child['remote_ts'] .= ",0.0.0.0/0,::/0";
+       $child['local_ts'] .= "";
+       $child['remote_ts'] .= "";
        return true;
 }

After this modification, the proposal no longer adds the catch all ranges and I can start the tunnel with the other side without issues.
This crude test worked as a proof of concept, if my feature request is considered and approved I can develop the whole solution (checkbox, etc) and submit it for review.

Actions
Copy link
 #1

Updated by Marcos M 20 days ago

It's not clear from the strongswan docs what the expected behavior is when local_ts/remote_ts is specified as an empty string. This feature can be considered once that's clarified.
https://docs.strongswan.org/docs/latest/swanctl/swanctlConf.html#_connections_conn_children

Actions
Copy link
 #2

Updated by Lisandro Massera 15 days ago

Thanks for the feedback. To clarify, my proposal is not to set `local_ts` or `remote_ts` to an empty string, nor to omit them entirely from the child definition.
The intent is only to avoid appending the additional catch-all selectors ,0.0.0.0/0,::/0
The existing traffic selectors defined for the Phase 2 remain intact and continue to populate `local_ts` and `remote_ts` normally.

My proof-of-concept modification was simply replacing:
$child['local_ts'] .= ",0.0.0.0/0,::/0";
$child['remote_ts'] .= ",0.0.0.0/0,::/0";
with no-op concatenations, so the configured selectors are preserved without adding the extra wildcard ranges.

For example, if the configured selectors are:

local_ts = 10.0.0.0/24
remote_ts = 10.1.0.0/24

then currently pfSense generates:

local_ts = 10.0.0.0/24,0.0.0.0/0,::/0
remote_ts = 10.1.0.0/24,0.0.0.0/0,::/0

whereas the proposed behavior would keep them as:

local_ts = 10.0.0.0/24
remote_ts = 10.1.0.0/24

The proposed checkbox would therefore only control whether the wildcard selectors are appended, while preserving current behavior by default for backward compatibility.

Actions
Copy link

Also available in: Atom PDF