Date: Fri, 27 Apr 2007 11:27:07 -0700 From: "Jon Simola" <jsimola@gmail.com> To: freebsd-pf@freebsd.org Subject: Re: why are pf-blocked ips 'leaking' thru to spamd? Message-ID: <8eea04080704271127g70d910bfg82ec652a0c6889bf@mail.gmail.com> In-Reply-To: <70f41ba20704271105m11fa5315kc7c3d715f2d63f61@mail.gmail.com> References: <70f41ba20704271105m11fa5315kc7c3d715f2d63f61@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/27/07, snowcrash <schneecrash+pf@gmail.com> wrote: > rdr pass on $ext_if proto tcp from { <spamd>, !<ip-black> } \ > to ($ext_if) > port 25 -> 127.0.0.1 port 8025 > rdr pass on $ext_if proto tcp from { !<spamd-white>, !<ip-black> } \ > to ($ext_if) > port 25 -> 127.0.0.1 port 8025 > so, iiuc, anything in <ip-black> should NEVER be redirected to spamd, > AND would be blocked anyway by the subsequent default filter ... Look at what the rules are being evaluated as with pfctl -vvnf : @0 rdr pass on em2 inet proto tcp from <spamd:0> to x.x.x.x port = smtp -> 127.0.0.1 port 8025 @1 rdr pass on em2 inet proto tcp from ! <ip-black:0> to x.x.x.x port = smtp -> 127.0.0.1 port 8025 @2 rdr pass on em2 inet proto tcp from ! <spamd-white:0> to x.x.x.x port = smtp -> 127.0.0.1 port 8025 @3 rdr pass on em2 inet proto tcp from ! <ip-black:0> to x.x.x.x port = smtp -> 127.0.0.1 port 8025 > but, in my spamd log i'm seeing, > > Apr 27 10:40:47 router spamd[984]: (GREY) 86.105.76.208: > <euguntersville@mit.midco.net> -> <snowcrash@mydomain.com> > Apr 27 10:40:47 router spamd[984]: 86.105.76.208: disconnected after > 1 seconds. > > > checking, > > % pfctl -t ip-black -T show | grep 86.104.0.0/14 > 86.104.0.0/14 > > where, > > % whatmask 86.104.0.0/14 | grep "t Usable" > First Usable IP Address = .....: 86.104.0.1 > Last Usable IP Address = ......: 86.107.255.254 > > so, why is the addr in question, 86.105.76.208, even getting to spamd? Because that block probably isn't in the spamd-white table, hence will be redirected and passed by rule @2 in the verbose output above. Multiple tables in rules are tricky because they are not treated as "sets" that can be arbitrarily compared (ie, IPs in table A that are not in table B). -- Jon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8eea04080704271127g70d910bfg82ec652a0c6889bf>