Date: Wed, 25 Jan 2023 11:07:37 +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-fsNsloPydU@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 #16 from dfr@rabson.org --- As far as I understand the code (which is not very well TBH), both nat and = rdr rules rely on both PF_IN and PF_OUT events but differ on which event trigge= rs state creation: PF_IN for rdr and PF_OUT for nat with the opposite event matching the other direction to reverse the re-write. For connections initiated locally, this symmetry is broken since we generate PF_IN events for the SYN causing the re-write and creating the state but si= nce there is no corresponding PF_OUT for the SYN+ACK reply, the connection fail= s. This is why I think we need PF_OUT for packets which will be delivered to t= he local stack rather than routed onward. I thought about whether it makes sense for rdr state creation to happen on PF_OUT but wouldn't that have other problems since the un-redirected destination address may direct the packet to the wrong outgoing interface? I haven't looked closely at upstream OpenBSD pf but it seems they have chan= ged the rule language considerably which would likely be a problem for FreeBSD unless there is a compability mode. I seem to remember that they support ta= bles for rdr target addresses which may be useful for managing a pool of load-balanced replicas. Anyway, for now I have a workable solution for my two (related) use-cases: 'publishing' container ports to the host for podman and mapping service VIP= s to containers for kubernetes. I'm looking forward to seeing the right solution= for this merged into main (and maybe stable/13). --=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-fsNsloPydU>