On Mon, Sep 27, 2004 at 09:00:03AM +0200, Wouter Schoot wrote:
> map ex0 10.0.0.33/32 -> 0/32 proxy port ftp ftp/tcp
> map ex0 10.0.0.33/32 -> 0/32 portmap tcp/udp 40000:60000
> map ex0 10.0.0.33/32 -> 0/32
> 
> Take the following line:
> block in quick on ex0 from any to 10.0.0.0/8
> 
> I put it there to prevent the outer networkcard (connected to the internet)
> from packets destinated for internal networks. I figured, they should not
> end up at my external interface.
> 
> But here's the catch. When I have that block rule enabled, machine A can't
> connect to the internet anymore. Connecting to 10.0.0.1 goes fine, but no
> internet anymore.
> 
> When I 'ipfstat -hi' with the rule enabled, and ping some on A to the
> internet, those requests do match the rule:
> 
> 8 block in quick on ex0 from any to 10.0.0.0/8
> 
> According to http://www.phildev.net/ipf/IPFques.html#11, the rules should
> apply in this order: "interface --> NAT --> filter --> OS --> filter --> NAT
> --> interface"

This means that packets coming from the network go though the NAT engine before
the packet filter engine. So when the packet hits the filter, its destination
address has already been changed.

> 
> I've been snooping on ex0 for 10/8 traffic using tcpdumps rule: tcpdump -n -i
> ex0 'net 10.0.0.0/8'.
> 
> It didn't show any rules when I pinged from A to the internet.
> 
> So the interface shouldn't even be seeing any of the 10.0.0.0/8 traffic. 

Yes, but tcpdump doesn't capture the packet at the same place as the
filter.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--