Feature #16438
openIPSEC VPN - support VTI tunnel to other firewall that doesn't do selector narrowing
0%
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.
No data to display