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>