Feature #3329: Allow creating "not" rules for IPsec Phase 2 - pfSense - pfSense bugtracker

Custom queries

2.4.5-p1 - Resolved/Closed
2.5.0 - Resolved/Closed
2.5.1 - Resolved/Closed
2.5.2 - Resolved/Closed
2.6.0 - Resolved/Closed
2.7.0 - Resolved/Closed
2.7.1 - All Open Issues
2.7.1 - Resolved/Closed
2.7.2 - Resolved/Closed
2.8.0 - All Open Bugs
2.8.0 - All Open Features
2.8.0 - All Open Issues
2.8.0 - All Open Regressions
2.8.0 - Feedback
2.8.0 - Needs Attention
2.8.0 - New/Confirmed
2.8.0 - Pull Requests
2.8.0 - Regressions affecting 2.7.0
2.8.0 - Resolved/Closed
21.02.2/2.5.1 - Resolved/Closed
21.05 Plus - All Closed Issues
21.05.1 Plus Target - All Closed Issues
21.05.1 Target - All Closed Issues
22.01 Plus - All Closed Issues
22.01 Target - All Closed Issues
22.05 Plus - All Closed Issues
22.05 Target - All Closed Issues
23.01 Plus - All Closed Issues
23.01 Target - All Closed Issues
23.05 Plus - All Closed Issues
23.05 Target - All Closed Issues
23.05.1 Plus - All Closed Issues
23.05.1 Target - All Closed Issues
23.09 Plus - All Closed Issues
23.09 Target - All Closed Issues
23.09.1 Plus - All Closed Issues
23.09.1 Plus - All Open Issues
23.09.1 Target - All Closed Issues
23.09.1 Target - All Open Issues
24.03 Plus - All Closed Issues
24.03 Plus - All Open Issues
24.03 Plus - Feedback Issues
24.03 Plus - Needs Attention/Work
24.03 Plus - New/Confirmed/In Progress Issues
24.03 Plus - Pull Request Review
24.03 Plus - Waiting on Merge
24.03 Target - All Closed Issues
24.03 Target - All Open Issues
All Open Issues assigned to Me
All Open Pull Requests
Any Target - All Open Regressions
Any Target - Feedback Issues
CE-Next - All Closed Issues (Move to specific target)
CE-Next - All Open Issues
CE-Next - Feedback (Likely needs target changed)
New Issues by Category - Future Target
New Issues by Category - No Target
New Issues by Category - No Target+Future
No Target - All Open Issues (Base Only)
No Target - New Issues (Base Only)
No Target - New Issues (Base and Packages)
Release Notes - Plus Target Version (DO NOT EDIT)
Release Notes - Target Version (DO NOT EDIT)

Actions

Copy link

Feature #3329

closed

Allow creating "not" rules for IPsec Phase 2

Added by Jim Pingle over 10 years ago. Updated over 3 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Renato Botelho

Category:

IPsec

Target version:

2.5.0

Start date:

11/19/2013

Due date:

% Done:

100%

Estimated time:

Plus Target Version:

Release Notes:

Description

We should have the ability in Phase 2 to negate the action ("none" in the SPD) so that specific traffic can be made to not enter an IPsec tunnel.

Somewhat related to #3328 (reordering P2 entries) so these exceptions can be moved above the other entries as needed.

These entries would not need to have any encryption options chosen, only the networks defined.

Files

shunt.png (21.9 KB) shunt.png

Markus Stockhausen, 07/28/2017 02:20 PM

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Jim Thompson over 9 years ago

Assignee set to Renato Botelho

Actions

Copy link

Updated by Ermal Luçi over 9 years ago

Now these should be called specifc policies.

Since phase2 is totally managed by the ipsec daemon there can be what is called shunt policies.
I am not sure where to put these on the GUI at this moment though!

Actions

Copy link

Updated by Chris Buechler over 9 years ago

Target version deleted (~~2.2~~)

not important for 2.2

Actions

Copy link

Updated by Markus Stockhausen over 6 years ago

This feature wil be really helpful. Lets assume a office firewall connected to a HQ firewall. It serves sub multiple small subnets via different interfaces. Lets assumes these are 10.11.12.0/24 (LAN) and 10.20.30.0/24 (OPT1). To build a working routing one would need tens of SAs and build them around the subnets.

A simple implementation could be a single checkbox for each SA. If it is set the local SA part will create a shunt entry in ipsec.conf

Actions

Copy link

Updated by Markus Stockhausen over 6 years ago

File shunt.png shunt.png added

Example implementation

Actions

Copy link

Updated by NCATS LAB over 5 years ago

Strongly Request feature.

We just lost a lot of time because this isn't implemented on SG-4860s.

On our REMOTE SG-4860, we has set up bridging for OPT1-OPT4 and couldn't figure out why everything worked to the GATEWAY except testing the DEF GW with PING.

System should be flexible enough to allow IPSEC tunnels on any interface without some background rule that only makes exceptions on LAN.

Thank-you

Actions

Copy link