Date: Fri, 27 Jan 2023 08:59:35 +0000 From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 268717] [pf] rdr rules don't work for traffic originating at localhost Message-ID: <bug-268717-16861-VKtCAq3Nv7@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-268717-16861@https.bugs.freebsd.org/bugzilla/> References: <bug-268717-16861@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268717 --- Comment #17 from Kristof Provost <kp@freebsd.org> --- (In reply to dfr from comment #16) > As far as I understand the code (which is not very well TBH), both nat an= d rdr rules rely on both PF_IN and PF_OUT events but differ on which event = triggers state creation: PF_IN for rdr and PF_OUT for nat with the opposite= event matching the other direction to reverse the re-write. Sort of. I find it more useful to think about when the packets pass through which parts of the stack. That does imply a direction (i.e. PF_IN/PF_OUT). In the normal case, when we're thinking of rdr, we'd be dealing with incomi= ng packets, arriving through ip_input(), triggering a PF_IN pf_test(). For the failing case described here we're dealing with packets that are generated locally, and the first time they hit the firewall is from ip_outp= ut() (i.e. pf_test(PF_OUT)). > For connections initiated locally, this symmetry is broken since we gener= ate PF_IN events for the SYN causing the re-write and creating the state bu= t since there is no corresponding PF_OUT for the SYN+ACK reply, the connect= ion fails. This is why I think we need PF_OUT for packets which will be del= ivered to the local stack rather than routed onward. For locally generated connections we're only getting the PF_IN after we've already had a PF_OUT. We can't usefully do anything on SYN+ACK packets, and= if we're trying to add an artificial PF_OUT we're just papering over a problem that started earlier. > I thought about whether it makes sense for rdr state creation to happen o= n PF_OUT but wouldn't that have other problems since the un-redirected dest= ination address may direct the packet to the wrong outgoing interface? I'm not sure I follow. > I haven't looked closely at upstream OpenBSD pf but it seems they have ch= anged the rule language considerably which would likely be a problem for Fr= eeBSD unless there is a compability mode. I seem to remember that they supp= ort tables for rdr target addresses which may be useful for managing a pool= of load-balanced replicas. Kajetan intends to keep the old syntax supported, at least for a while. I s= till need to look at his work in detail, which I don't expect to be able to do before the end of February. > I'm looking forward to seeing the right solution for this merged into mai= n (and maybe stable/13). To be clear, I'm not making any promises about the time and effort I can sp= end on this. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-268717-16861-VKtCAq3Nv7>