Page MenuHomeFreeBSD

pf: Support killing floating states by interface
ClosedPublic

Authored by kp on May 13 2021, 11:49 AM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 16 2024, 5:23 AM
Unknown Object (File)
Dec 27 2023, 4:10 AM
Unknown Object (File)
Dec 23 2023, 12:19 AM
Unknown Object (File)
Dec 20 2023, 5:06 PM
Unknown Object (File)
Oct 26 2023, 11:57 PM
Unknown Object (File)
Sep 24 2023, 7:55 PM
Unknown Object (File)
Sep 3 2023, 4:05 AM
Unknown Object (File)
Aug 10 2023, 6:19 AM

Details

Summary

Floating states get assigned to interface 'all' (V_pfi_all), so when we
try to flush all states for an interface states originally created
through this interface are not flushed. Only if-bound states can be
flushed in this way.

Given that we track the original interface we can check if the state's
interface is 'all', and if so compare to the orig_if instead.

MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kp requested review of this revision.May 13 2021, 11:49 AM
eri requested changes to this revision.May 13 2021, 3:25 PM
eri added a subscriber: eri.

This kind of breaks the assumption of floating states, 'it will apply in any interface any direction'.
These states can be killed through src/dst options, or potentially you can do this in a daemon managing states in userland and killing states by id.

I know there is a use-case in pfSense for this but in itself pfSense overloaded the meaning of floating state and has patches internal patches to deal with it. IIRC this is a by product of that.

This revision now requires changes to proceed.May 13 2021, 3:25 PM
In D30246#679309, @eri wrote:

This kind of breaks the assumption of floating states, 'it will apply in any interface any direction'.

The usual state matching still applies, so the state will still be match traffic irrespective of interface.

These states can be killed through src/dst options, or potentially you can do this in a daemon managing states in userland and killing states by id.

Yes, but without it there's no way to say 'kill states originating on interface X' (assuming floating states, of course). It intuitively makes no sense to be unable to kill states (in this way) simply because we're less strict about matching them.

I know there is a use-case in pfSense for this but in itself pfSense overloaded the meaning of floating state and has patches internal patches to deal with it. IIRC this is a by product of that.

pfSense currently has a fairly hacky solution to this where it basically hardcodes all states to be if-bound, but then undoes that in the state matching code. That obtains the same result (i.e. we can kill floating states by their interface), but has a lot more fallout that this.

This revision was not accepted when it landed; it landed in state Needs Revision.May 20 2021, 11:55 AM
This revision was automatically updated to reflect the committed changes.