On 2023-09-04 22:53 +02, Alexander Bluhm <[email protected]> wrote: > On Mon, Sep 04, 2023 at 03:58:02PM +0200, Alexandr Nedvedicky wrote: >> 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. > > I think we are bikeshedding the solution for a problem that nobody > had in real life for 20 years. > > Peter wants to block the packets and Florian wants sloppy rules.
No, I don't. I only jumped in here because of this: >> > You proposed fix means that our default pf would block icmp error >> > packets now. >> > >> > block return # block stateless traffic >> > pass # establish keep-state >> > >> > To have the old behaviour one would write >> >> I think icmp error message, if legit, is allowed because it matches >> state created by 'pass' rule. At least this is my understanding. >> >> Or is there something else going on which I'm missing? > > If icmp packets are legit, they work with the existing pass keep-state > rule in default pf.conf. > > For passing unrelated icmp packets, e.g. with assymetric routing, > one can add a pass no-state rule. Over a decade ago I ran a network with asymmetric routing. I recall that we were trying no-state and sloppy. Both could be made to work. I no longer run such a network and I don't have one in my lab either, so I can't test your diffs. What I'm saying is: If you change the semantics of pf where a previous working ruleset suddenly drops ICMP errors because there is no associated state this will bite people with asymmetric routing. Because it will break PMTU and it's going to be a pain to figure out what's going on. Things to consider are no-state and sloppy. -- In my defence, I have been left unsupervised.
