Cédric Berger wrote:
Forrest Aldrich wrote:
I've a few geoip orientated tables for which I want to block certain traffic.

I'm able to match the addresses via pfctl, though the connections from these IP spaces are still getting through, and I'm puzzled.

I rdr inbound connections to an RFC addressed server. All mail and web are working fine, but these tables are not blocking. I confirm this by watching the logs for rejected messages (I augment the filter with an MTA access list).
[...]
tcp_services = "imap, imaps, smtp, smtps"
[...]
# REDIRECTION
rdr pass on $ext_if inet proto tcp from any to ($ext_if) \
    port { $tcp_services } -> $server
Here, in the "nat step", by using "rdr PASS ..." you tell PF that there is no need to evaluate further the packet in the following "filter step". Packet
matching the rdr condition here will just PASS.
[...]
# HERE ARE THE TABLE/BLOCK RULES I MENTIONED
block in quick on $ext_if proto { tcp, udp } from { <geoip-apnic>, <geoip-lacnic>, <geoip-afrinic>, <geoip-ripe> } \
    to $ext_ad port 25

block in quick on $ext_if from <abuse>

block in quick on $ext_if proto { tcp, udp } from <spammers> to $ext_ad port 25

So these rules are never evaluated for packets matching the early RDR.

You should remove the "pass" on the RDR rule, this "pass" attribute is
very convenient for small rulesets or quick-n-dirty tests, but in more
complex rulesets like this one, they are usually not used.

Cedric

I combined the geoip list into one table, to make this easier.

I have the following in place:

rdr on $ext_if inet proto tcp from any to ($ext_if) \
   port { $tcp_services } -> $server

rdr pass on $ext_if inet proto tcp from any to ($ext_if) \
   port 80 -> $server
rdr pass on $ext_if inet proto tcp from any to ($ext_if) \
   port 443 -> $server
nat on $ext_if inet from ($int_if:network) to any -> ($ext_if)
Note I removed "pass" from the first rdr and that appears to work.

However, if I remove "pass" from the http redirects, it does NOT work, and I'm stumped as to why. I tried several variations on the rdr based on examples, and I believe that is correct (minus the pass).

Is there a problem with RDR and http that I'm not aware of?

The only rules before that are:

scrub all reassemble tcp no-df
scrub in all fragment reassemble scrub out all random-id

and I don't believe those would affect this.


Thanks.




Reply via email to