Subject: Re: ipf and ipnat and unrelated 1.4.2 Observations
To: None <firstname.lastname@example.org>
From: Dean Huxley <email@example.com>
Date: 04/14/2000 15:25:33
[ moved to current-users because this isn't port specific ]
Thor Lancelot Simon <firstname.lastname@example.org> 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?