Date: Fri, 6 Jan 2012 16:13:00 +0100 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Gerald McNulty <gmnt99@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: Basic transparent filtering with pf Message-ID: <20120106151300.GB24312@insomnia.benzedrine.cx> In-Reply-To: <CAD%2B_bPzGMEv77XS4bNUjE18Mrf4mLe6S1b43mKF6PkXzJxR6dg@mail.gmail.com> References: <CAD%2B_bPy94dRyzfQDEnzXB%2BsffVnO6AhTMOidJwHPSO%2B=tkYBFQ@mail.gmail.com> <20120106074225.GA24312@insomnia.benzedrine.cx> <CAD%2B_bPzGMEv77XS4bNUjE18Mrf4mLe6S1b43mKF6PkXzJxR6dg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 06, 2012 at 02:21:07PM +0000, Gerald McNulty wrote: > I don't understand how rerouting the the loopback address would solve this. > There are 2 steps here - first the TCP handshake needs to be completed and > then the kernel/pf needs to pass the packets to the correct socket. How is > this supposed to work in pf? Or is this hidden/implicit in certain rule > definitions? After looking at ip_input.c and searching for M_FASTFWD_OURS, I think this only works with ipfw. Forwarding to loopback and the uid lookup are just what triggers it in ipfw, pf never sets that mbuf tag. You can use pf and ipfw both at the same time, but for IP_BINDANY to do anything useful, you need that magic ipfw rule, to mark replies as belonging to a local socket (even though the destination address is non-local). Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120106151300.GB24312>