Subject: Re: ipf and ipnat and unrelated 1.4.2 Observations
To: None <tls@rek.tjls.com>
From: Dean Huxley <dean@huxley.org>
List: current-users
Date: 04/14/2000 15:25:33
[ moved to current-users because this isn't port specific ]

Thor Lancelot Simon <tls@rek.tjls.com> wrote:
> On Tue, Apr 11, 2000 at 12:50:23PM -0700, Steve wrote:
> > Greetings, two things:
> > 
> > IPF/IPNAT-
> > Although not specifically port-i386 specific, is there
> > any documentation on ordering of  ipf and ipnat ?
> > 
> > It appears ipnat is layered below ipf, such that
> > rdr's placed in ipnat bypass any blocks set in
> > ipf.  Is this the implemented architecture?
> 
> No.  NAT does run *first*, but IPF still sees the packets -- it just sees
> the addresses as rewritten by NAT.
> 
> No, this isn't obvious, but it's how it's always been and changing it would
> break a lot of people's NAT/IPF rules.

I'm confused.  How does ipf know when an address has been rewritten by
NAT or not?  ie. How do I make sure people outside the firewall can't
send packets directly to internal IP addresses?


I just upgraded from 1.4.1 to current and now ipf & ipnat are acting
differently.  With 1.4.1 I used the following rule to ensure outside
hosts couldn't send directly to inside hosts.

block in log quick on ex1 from any to 192.168.1.0/24

Now, on current, this rule is preventing internal hosts from
communicating to the outside world.

It seems to me that in 1.4.1 it was IPF first, IPNAT second.
In current it is reversed: IPNAT first, IPF second.

To get my internal hosts working I'll have to delete the ipf rule.
I'll have to rely on the "non-routableness" of 192.168.0.0, but
I'd feel more comfortable if I could block things explicitly.

Is it just me or does something seem really wrong here?