freebsd security - May 2003 - Packet flow through IPFW+IPF+IPNAT ?

Hi.

   On my FreeBSD 4.8 configured IPFW2+IPF+IPNAT and I use them all:
   - IPFW - traffic accounting, shaping, balancing and filtering;
   - IPFilter - policy routing;
   - IPNAT - masquerading.
   I want to know, how IP-packets flow through all of this components?
What's the path?
   incoming: IPFW Layer2 -> IPFW&Dummynet -> IPNAT -> IPFilter ?
   outgoing: IPFW Layer2 -> IPFW&Dummynet -> IPFilter -> IPNAT ?
Is this correct? Or IPNAT on the incoming packets run before IPFW L3:
   incoming: IPFW Layer2 -> IPNAT -> IPFW&Dummynet -> IPFilter ?
I think this path is more preferable, because IPFW always use not
masqueraded IP-headers.

Any help appreciated.

I don't use IPFW and IPFilter together, but IIRC IPFilter steps between
everything else (except for bpf) and the interface. Same for IPNAT, which
integrates with IPFilter.

Since the advent of pf and altq, OpenBSD has had a better firewall
architecture than any of the other BSDs, IMHO. pf can do things which are
awkward in other systems because features were kludged in later.

I've always thought that it would be cool to be able to integrate firewall
components into FreeBSD via its unique NetGraph system. This would let you
filter specific flows of packets very efficiently.

--Brett

On Sat, 31 May 2003, Vandyuk Eugene wrote:
>    Hi.
>
>    On my FreeBSD 4.8 configured IPFW2+IPF+IPNAT and I use them all:
>    - IPFW - traffic accounting, shaping, balancing and filtering;
>    - IPFilter - policy routing;
>    - IPNAT - masquerading.
>    I want to know, how IP-packets flow through all of this components?
> What's the path?
>    incoming: IPFW Layer2 -> IPFW&Dummynet -> IPNAT -> IPFilter
?
>    outgoing: IPFW Layer2 -> IPFW&Dummynet -> IPFilter -> IPNAT
?
> Is this correct? Or IPNAT on the incoming packets run before IPFW L3:
>    incoming: IPFW Layer2 -> IPNAT -> IPFW&Dummynet -> IPFilter
?
> I think this path is more preferable, because IPFW always use not
> masqueraded IP-headers.
>
> Any help appreciated.
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to
> "freebsd-security-unsubscribe@freebsd.org"
>
I have ipfw compiled in and run ipfilter as a kld

the way it works is ipfw -> ipnat -> ipfilter

ipnat and all state matching for ipfilter is performed prior to ruleset
processing

-- 
Matthew George
SecureWorks Technical Operations

On Thu, Jun 05, 2003 at 01:39:25PM +1000, Darren Reed
wrote:
> In some mail from Fernando Gleiser, sie said:
> > 
> > >    OUTGOING:  IPF -> IPNAT -> IPFW
> > >    INCOMING:  IPFW -> IPNAT -> IPF
> > 
> > There was some discusion some time ago in ipf's mailing list. I
don't remember
> > Darren's position on this.
> 
> My perspective is that it best serves IPFilter for it to be like that.
> 
> I'm not sure why it isn't, except to say that it's entirely
possible that
> I have applied a patch incorrectly.
> 
> Darren
But it's no so hard to move IpHack section in ip_input.c to call after IPFW
proxessing? In this way we can keep all of the functionality all of IPFW,
IPFilter and IPNAT. Because now people who want to use IPNAT with his kernel
processing (versus NATd with userland processing) forced to use IPFilter and
fully rebuild their firewall.
   It's some trouble with this changes in ip_input.c processing ?