Project

General

Profile

Actions

Todo #9356

closed

Find optimal default for net.pf.request_maxcount

Added by Jim Pingle over 5 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
Start date:
02/27/2019
Due date:
% Done:

10%

Estimated time:
Plus Target Version:
Release Notes:

Description

FreeBSD 12 introduced a new sysctl, net.pf.request_maxcount, which must be set in loader.conf (or loader.conf.local). This is a security measure to prevent a pf DoS from large transactions, but it also can interfere with large table manipulations and other similar bulk changes.

  The kernel will reject very large tables to avoid resource exhaustion
  attacks. Some users run into this limit with legitimate table
  configurations.

  The error message in this case was not very clear:

      pf.conf:1: cannot define table nets: Invalid argument
      pfctl: Syntax error in config file: pf rules not loaded

  If a table definition fails we now check the request_maxcount sysctl,
  and if we've tried to create more than that point the user at
  net.pf.request_maxcount:

      pf.conf:1: cannot define table nets: too many elements.
      Consider increasing net.pf.request_maxcount.
      pfctl: Syntax error in config file: pf rules not loaded

For the moment, pfSense 2.5.0 will set this tunable to the same value as the max table entries option: 400,000. There is a field to change it, and since it is a loader tunable this requires a reboot to activate.

This could also potentially interfere with state table operations, and may require the value set at 2x the actual number of entries that could change at once, to cover both the delete and add actions.

The chosen default may be OK, but needs testing and validation on systems with large tables (state tables, HA, alias table entries, etc), such as users with many pfBlocker lists for one example.

Actions #1

Updated by Jim Pingle almost 5 years ago

This sysctl is on 2.4.5 as well, and the method described here is what we've used so far. The details of that are on #10254

I'm leaving this open for now in case we find a better method to derive the value for 2.5.0.

Actions #2

Updated by Jim Pingle about 4 years ago

  • Status changed from New to Closed

This has been working fine.

Note that it changed from a loader tunable to a run-time sysctl in FreeBSD stable/12 for 2.5.0: #10861

Actions

Also available in: Atom PDF