Bug #13049
closed
Empty ``negate_networks`` table breaks policy routing rules
Added by Marcos M over 2 years ago.
Updated over 2 years ago.
Plus Target Version:
22.05
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.
Examples of when this can happen are:
- 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
.
- Assignee set to Viktor Gurov
- Status changed from New to Pull Request Review
- Target version set to 2.7.0
- Plus Target Version set to 22.05
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
- 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.
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
- Status changed from Feedback to Pull Request Review
- Status changed from Pull Request Review to Feedback
- Status changed from Feedback to Resolved
Tested in systems which would and would not require negate_networks and it worked as expected.
Also available in: Atom
PDF