ipfw/nated stateful rules example

[fbsd_user]

As the original poster of this thread, I want to say thank you to
Ken Bolingbroke who posted his rule set and to the other posters who
voiced their comments.

I want to point out that Ken Bolingbroke acknowledged that has work
around of doing keep-state on both the Lan interface and the public
interface only works because the returning public packet is being
matched by stateful table entries posted from the Lan interface
keep-state rules. Yes he provided he could make it work, but not
work correctly. In the true security sense, this is un-secure and
invalidates the whole purpose of using keep-state rules at all.

I an surprised that I have not yet heard the old timers dogma that
the Nated process it self is really performing an keep-state like
process and that is why keep-state does not work with divert/Natd.
There is some truth to that because the Nat process does have to
keep it's own internal table to remap IP address, but it just
blindly does the mapping with out any regard to if the packet
belongs to an authorized session conversation, like the keep-state
function does.

The conclusion so far is that ipfw1 and ipfw2 using keep-state rules
on the interface facing the public internet with divert/nated does
not work period. By all accounts this is an long time bug propagated
by the continued use of the legacy divert keyword sub-routine call
to ipfw's userland Natd function. The using of keep-state rules on
the interface facing the public internet is restricted to situations
where there are no Lans behind the ipfw firewall or when 'user
ppp' -NAT function is used. I have tested using ipnat as an front
end to ipfw with keep-state but that also ends up handing off the
packet to ipfw at the wrong time.

Now that ipfw2 has replaced ipfw1 in 5.2, maybe some of that ipfw2
programming teams effort can be directed at fixing this problem. The
IPNAT code of IPFILTER runs in the kernel and could be modified to
be ipfw2's external Nat function.

So firewall users who want the maximum level of protection have to
use IPFILTER. IPFILTER has had the keep state function long before
the keep-state option was ever added to ipfw1.

Still would like to be provided wrong on my conclusion.






-----Original Message-----
From: Micheal Patterson [mailto:micheal at tsgincorporated.com]
Sent: Tuesday, January 20, 2004 12:50 AM
To: Ken Bolingbroke; fbsd_user
Cc: freebsd-questions at freebsd.org
Subject: Re: ipfw/nated stateful rules example


----- Original Message -----
From: "Ken Bolingbroke" <hacker at bolingbroke.com>
To: "fbsd_user" <fbsd_user at a1poweruser.com>
Cc: <freebsd-questions at freebsd.org>
Sent: Monday, January 19, 2004 10:28 PM
Subject: RE: ipfw/nated stateful rules example


>
> On Mon, 19 Jan 2004, fbsd_user wrote:
>
> > That's a play on words. And still does not prove stateful rules
work on
> > the interface facing the public internet. There is no
documentation that
> > says keep-state and limit only works on the interface facing the
private
> > Lan network. And the implied meaning is they are to be used on
the
> > interface facing the public internet.
>
> I just jumped in the middle here, so I may be out of context.
>
> But, stateful rules don't play nice with NAT.  Consider non-NAT, a
public
> IP address contacting an Internet address:
>
>   67.161.59.61 -> 66.218.71.91
>
> A rule is created for 66.218.71.91 coming to 67.161.59.61.  When
> 66.218.71.91 replies, the stateful rule lets it in.  This is good.
>
>
> But consider NAT:
>
>  10.0.0.10 changed to 67.161.59.61 -> 66.218.71.91
>
> If you do a keep-state before NAT, you have a rule to allow
66.218.71.91
> to 10.0.0.10, but the return incoming packet will be
66.218.71.91 ->
> 67.161.59.61, so the rule doesn't match.
>
> If you do a keep-state after NAT, then you have a rule to allow
> 66.218.71.91 to 67.161.59.61.  The return incoming packet matches
that
> rule, but it accepts the packet and packet processing stops, so
it's never
> passed through NAT, and never makes it back to 10.0.0.10.
>
>
> So as it stands now, I don't see that you can use stateful
connections
> with NAT, unless check-state is changed to allow a packet to be
passed
> through NAT.
>
> Ken Bolingbroke

Ken, try this one. This is what I use here at home and it does
indeed work:

Launch NATD with natd -interface ep0 -s -m -u (Only RFC1918 packets
get
altered)

## Divert everything to NAT.
ipfw add 1 divert natd ip from any to any via ep0

#Prevent inbound spoof attempts for my lan range
ipfw add 10 deny ip from 192.168.1.0/24 to any in via ep0

#Check State Rules
ipfw add 20 check state

#LAN Allow Stateful
ipfw add 31 allow ip from 192.168.1.0/24 to any keep-state

#Allow Outbound Stateful.
ipfw add 40 allow ip from 68.12.xx.xx to any keep-state

NAT keeps a seperate table of it's translations to provide a back
channel.
Traffic comes in, generates a dynamic ruleset, gets translated,
heads out
and creates the 2nd dynamic for the packet. You'll end up with
something
like this

ipfw -d list

<snip>

## Dynamic rules:
00040 4 692 (T 18, slot 215) <-> tcp, 68.12.xx.xx3777<->
216.239.57.99 80
00031 35 20374 (T 10, slot 219) <-> udp, 192.168.1.3 4986<->
198.247.231.41
27019
00031 3 216 (T 1, slot 483) <-> tcp, 192.168.1.1 22<-> 192.168.1.2
3574
00031 16 11902 (T 298, slot 752) <-> tcp, 192.168.1.2 3777<->
216.239.57.99
80

Granted, you'll end up with a dual entry for each packet in stateful
space,
but it does work. Perhaps not as intended with a single match but
you can
use statful with NAT.


--

Micheal Patterson
Network Administration
TSG Incorporated
405-917-0600