Hello,
On Mon, Sep 04, 2023 at 03:28:00PM +0200, Alexander Bluhm wrote:
> On Sun, Sep 03, 2023 at 11:00:56PM +0200, Alexandr Nedvedicky wrote:
> > Hello,
> >
> > On Sun, Sep 03, 2023 at 09:26:29PM +0200, Florian Obser wrote:
> > > FYI, I'm not using sloppy, and I don't have a network with asymmetric
> > > routing
> > > at the moment. I only remembered that we used sloppy for a while at my
> > > previous job. I think we settled on no-state because it was faster than
> > > sloppy and less hastle.
> > >
> >
> > From my perspective 'no state' vs. 'keep state (sloppy)' are valid
> > approaches.
> > Both are equally good. Perhaps 'no state' option keeps code bit more
> > simple.
> > Because if we will go with sloppy state, then we need to include a small
> > tweak to pf_test_rule() too, so 'keep state' (and nat-to) are not
> > ignored.
>
> I do not think that ICMP error messages should create a state. If
> the rule is sloppy, just pass them. nat-to does not work in this
> case, but I would ignore that. If you use sloppy states, don't be
> surprized about strange effects in corner cases.
>
Understood. However would not be better to allow 'unsolicited' icmp
error messages by 'no state' rules only? Such approach makes me
slightly more comfortable, because the ruleset behavior is bit more
predictable:
keep state
keep state (sloppy)
don't match ICMP error replies, because those should match
existing state.
no state
option can match any packet (including 'unsolicited' icmp error
replies) so firewall admins can deploy workarounds to address some
awkward corner cases
may be I'm overthinking it given the issue has not been noticed for ages.
thanks and
regards
sashan
