Firewall: Rules - Per-rule adaptive timeouts

[ganguin]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

I manage a setup with global adaptative timeout. Additionally, I have a max-src-state directive such that a single source cannot fill the global state table. However, with this configuration the adaptative timeout does not kick in when a user reaches his max-src-state. pf allows to configure the adaptative timeout directive on a rule, alongside with max-src-state, but the OPNsense configuration does not allow to set the adaptative timeout on a firewall rule.

The global adaptative seeting are present in /system_advanced_firewall.php under Firewall Adaptive Timeouts (values start and end).

The same options are missing in /firewall_rules_edit.php?if=xxx (all interfaces) in the Advanced Options alongside with "Max states" or "Max source states".

Describe the solution you like

Add the adaptative timeout start and end fields in the advanced rule configuration (in /firewall_rules_edit.php?if=xxx) together with "Max source states" such that the pf rule would end up like this:

pass from XXX to YYY keep state (max-src-states <nnn>, adaptive.start <mmm>, adaptive.end <ooo>)

With an agressive start and end configuration, a user coming close to his Max source states will likely not experience packet drop because of the timeout becoming really short.

Describe alternatives you considered

Globally shortening TCP timeouts is not really an option, as the defaults are sane values. Tuning the global adaptative timeouts comes either with the problem that one src could impact all others on the network or the src with a lot of states experiencing packet losses; there seem not to be a setting were both can be satisfied without the per rule adaptative settings.

[kulikov-a]

Hi. (im the one that answered on forum)
Are you sure that the default coefficients (0.6/1.2) used by the pf to calculate the per rule adaptive.start, adaptive.end depending on the "Max states" value are not enough?
if you set "Max states" = 1000 in GUI for specific rule it should give something like
.. keep state (max 1000, adaptive.start 600, adaptive.end 1200) label .. imho

[ganguin]

I'm using max-src-states, not max states, but afaik it doesn't matter.

I did a lot of testing, and for our use case the default adaptative timeouts are not aggressive enough. The settings we came up we're more aggressive than default (iirc adaptative.end just 5% over the max) such that the it gets to a factor of 50 times down the default (120s TCP connect timeout down to about 2.4s when the state table reaches the max).

With the defaults we had multiple connection drop issues when getting a lot of connections.

We can maybe find another tuning that will fit our needs. But it'll save us a lot of time if we can replicate the setup that we already intensively tested.

[kulikov-a]

@ganguin thanks! (well reasoned imho)

[kulikov-a]

@ganguin hi. can you try with
opnsense-patch -a kulikov-a f8e8023 ?
(should add more validations before the pr if this is what you expect and @AdSchellevis with @fichtner are not against the idea itself) )

[ganguin]

@kulikov-a I'm impressed that was fast. Thank you for your job.
Yes, it creates the expected pf rule. I tested it again, I experience almost no packet drop when coming close to the max states.

[fichtner]

@kulikov-a I'm sure @AdSchellevis wouldn't mind a PR for further discussion of f8e8023

[kulikov-a]

@fichtner great, thanks! will add additional validations and make a pr

[AdSchellevis]

added in b01da7a