Doug Hardie wrote:
1. pf allows short cuts, but these also makes it more difficult to debug. I'd
separate NAT from filtering,
Ok. I guess you want some white space between them? Here it is with the white
space and comments:
ext_if="dc0"
table <blackhole> persist file "/etc/blackhole"
table <spamd> persist
table <spamd-white> persist
table <spamd-white-local> persist file "/etc/mail/whitelist"
MAILHOSTS = "{zool.lafn.org}"
# NAT/RDR Rules
no rdr on { lo0, lo1 } from any to any
no rdr inet proto tcp from <spamd-white-local> to any port smtp
no rdr inet proto tcp from <spamd-white> to any port smtp
rdr pass log inet proto tcp from any to any port smtp -> 127.0.0.1 port spamd
# Filter Rules
pass in log inet proto tcp to $MAILHOSTS port smtp keep state
pass in log on sis0 reply-to (sis0 192.168.25.1) proto tcp from any to any port
75 keep state
block in quick log on $ext_if from <blackhole> to any
Other than the comments I don't see the difference.
you didn't separate nat from filtering, and you didn't add interfaces on
your rdr rules. When you make these shortcuts, maybe your ruleset
becomes more compact, maybe it works, but it becomes more difficult to
debug.
that is never use "rdr pass" even though pf allows it. You also need to
understand when rdr takes place to write your filtering rules.
That would be really helpful if that information were available somewhere it could be found. I have not been able to find that anywhere.
Basically, for rdr, the address translation takes place before the
packet is parsed by the filter rules. For nat, it takes place after the
filtering. For binat, you can think of it as nat in one direction rdr in
the other.
This is for the first packet, keep state and you don't have to worry
about the rest.
se also,
http://www.openbsd.org/faq/pf/rdr.html
http://www.openbsd.org/faq/pf/nat.html
2. you can deploy one of two policies: Default block with a whitelist or
default pass with a black list. Mixing these is a bad idea.
This is one thing you should see to clarify in your ruleset above. When
you have both whitelist and blacklist what happens to those that are in
neither? what happens to those that are in both.
Which default policy makes sense depends on the service. You may want to
use black lists for smtp but whitelist for ssh for example.
anyway, to interpret the output of pflog, you need the output from pfctl -sr
and pfctl -sn rather than your config file.
zool# pfctl -sr
No ALTQ support in kernel
ALTQ related functions disabled
pass in log inet proto tcp from any to 206.117.18.7 port = smtp flags S/SA keep
state
pass in log on sis0 reply-to (sis0 192.168.25.1) inet proto tcp from any to any
port = 75 flags S/SA keep state
block drop in log quick on dc0 from <blackhole> to any
so your filter rules are numbered 0, 1, 2
zool# pfctl -sn
No ALTQ support in kernel
ALTQ related functions disabled
no rdr on lo0 all
no rdr on lo1 all
no rdr inet proto tcp from <spamd-white-local> to any port = smtp
no rdr inet proto tcp from <spamd-white> to any port = smtp
rdr pass log inet proto tcp from any to any port = smtp -> 127.0.0.1 port 8025
your rdr rules are numbered 0, .. 4, but you only have log in rule 4.
So, when you see matches in your pflog, rule 0 .. 2 are filter rules and
rule 4 is rdr rule, which you can also see from the action logged, pass,
block or rdr. That seems to explain why you have no matches for rule 3.
So, to solve your problem, separate first NAT and filtering. Things becomes so
much more clear.
Repeated: Get rid of that "rdr pass" make an rdr rule and a pass rule.
Yes, it's the rule recommended by the spamd man page, but if you want to
see and understand what's going on, that kind of rules can really make
things obscure.
BR, Erik
--
Erik Nørgaard
Ph: +34.666334818/+34.915211157 http://www.locolomo.org
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"
