Bug #13049
closedEmpty ``negate_networks`` table breaks policy routing rules
100%
Description
When negate_networks
is empty, is effectively behaves the same as any
. In cases where the negate_networks
table ends up empty, policy routing rules will not work due to the automatic NEGATE_ROUTE
rule above it catching all traffic.
- Using an OpenVPN client without specifying a tunnel network with an interface assigned for use in policy routing
- A second WAN for use in policy routing
Using the second example as a test, this leads to the ruleset:
table <negate_networks> [...] pass in quick on $LAN inet proto tcp from any to <negate_networks> ridentifier 10000001 flags S/SA keep state label "id:1649718619" label "gw:WAN2GW" label "NEGATE_ROUTE: Negate policy routing for destination" pass in quick on $LAN $GWWAN2GW inet proto tcp from any to any ridentifier 1649718619 flags S/SA keep state label "id:1649718619" label "gw:WAN2GW" label "USER_RULE"
With this, traffic ends up matching the
NEGATE_ROUTE
rule and is routed through WAN1GW
rather than WAN2GW
.Tested on
22.01
and 22.05.a.20220410.0600
.
Updated by Viktor Gurov over 2 years ago
- Assignee set to Viktor Gurov
Updated by Jim Pingle over 2 years ago
- Status changed from New to Pull Request Review
- Target version set to 2.7.0
- Plus Target Version set to 22.05
Updated by Viktor Gurov over 2 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 415a1b2083228030f200c8ea0eac3a8fc91f7142.
Updated by Jim Pingle over 2 years ago
- Subject changed from Empty negate_networks table breaks policy routing rules to Empty ``negate_networks`` table breaks policy routing rules
Updating subject for release notes.
Updated by Marcos M over 2 years ago
This introduces a significant delay to building the filter ruleset due to the introduction of $vpns_list = filter_get_vpns_list();
within filter_generate_user_rule()
. Fix https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/734
With 415a1b2083228030f200c8ea0eac3a8fc91f7142
applied:
[22.05-DEVELOPMENT][root@gw]/root: time /etc/rc.filter_configure_sync 20.046u 35.804s 0:44.79 124.6% 665+201k 66665+37io 1pf+0w
With
415a1b2083228030f200c8ea0eac3a8fc91f7142
reverted:[22.05-DEVELOPMENT][root@gw]/root: time /etc/rc.filter_configure_sync 5.025u 2.171s 0:06.80 105.7% 612+199k 2452+2532io 22pf+0w
With fix applied:
[22.05-DEVELOPMENT][root@gw]/root: time /etc/rc.filter_configure_sync 5.053u 2.184s 0:06.86 105.3% 601+193k 2458+2532io 22pf+0w
Updated by Marcos M over 2 years ago
- Status changed from Feedback to Pull Request Review
Updated by Marcos M over 2 years ago
- Status changed from Pull Request Review to Feedback
Applied in changeset a250063f87eae118e7d3be6d207cfb4a8858fb7a.
Updated by Marcos M over 2 years ago
- Status changed from Feedback to Resolved
Tested in systems which would and would not require negate_networks and it worked as expected.