Project

General

Profile

Actions

Bug #13049

closed

Empty ``negate_networks`` table breaks policy routing rules

Added by Marcos M over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
High
Assignee:
Viktor Gurov
Category:
Rules / NAT
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:

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.

Actions #1

Updated by Viktor Gurov over 2 years ago

  • Assignee set to Viktor Gurov
Actions #2

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
Actions #3

Updated by Viktor Gurov over 2 years ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #4

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.

Actions #5

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

Actions #6

Updated by Marcos M over 2 years ago

  • Status changed from Feedback to Pull Request Review
Actions #7

Updated by Marcos M over 2 years ago

  • Status changed from Pull Request Review to Feedback
Actions #8

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.

Actions

Also available in: Atom PDF