Victor Sudakov wrote:
[snip]
>
> I have looked at your ruleset. First you have:
>
> [dd]
>> $fwcmd add divert natd ip from any to me in via ppp0
>> $fwcmd add divert natd ip from 10.10.0.0/8 to any out via ppp0
>> $fwcmd add check-state
>>
>
> [dd]
>
> and only later you have your keep-state rules:
>
>>
>> $fwcmd add allow udp from any to any via ppp0 keep-state
>> $fwcmd add allow log icmp from any to any icmptypes 3,4
>>
>> $fwcmd add allow tcp from any to me 80 via ppp0 keep-state
>>
>> $fwcmd add deny log tcp from any to any in recv ppp0 setup
>> $fwcmd add allow tcp from any to any out xmit ppp0 setup keep-state
>> $fwcmd add allow tcp from any to any via ppp0 established keep-state
>
> This means your dynamic rules will contain an already NAT-ted address,
> which is useless.
>
> With my example ruleset below, where would you put the keep-state
> option?
>
>
> 00100 divert 8668 ip from any to table(1) out via rl0
> 00200 deny log logamount 100 ip from 10.0.0.0/8 to any out via rl0
> 00300 deny log logamount 100 ip from 172.16.0.0/12 to any out via rl0
> 00400 deny log logamount 100 ip from 192.168.0.0/16 to any out via rl0
>
> 00500 divert 8668 ip from table(1) to any in via rl0
> 00600 check-state
^^^^^^^^^^^
Yes - the check-state line is required first in order to make use of the
keep-state line later in the ruleset.
00650 allow ip from table(1) to any in via rl0 keep-state
Or wherever you are intending to set up state for a rule in the state table.
> 00700 deny log logamount 100 ip from any to 10.0.0.0/8 in via rl0
> 00800 deny log logamount 100 ip from any to 172.16.0.0/12 in via rl0
> 00900 deny log logamount 100 ip from any to 192.168.0.0/16 in via rl0
>
> 65535 allow ip from any to any
>
>
$fwcmd add allow tcp from any to any out xmit ppp0 setup keep-state
$fwcmd add allow tcp from any to any via ppp0 established keep-state
Note in these two rules the setting of the SYN flag with "setup". This
allows the initial 3-way TCP handshake. The subsequent "established" line is
where it will "remember" the traffic. It is not truly necessary to have it
split between two lines like this, as a looser example:
$fwcmd add allow tcp from any to me 80 via ppp0 keep-state
Of course, you will need to adjust for the direction(s) of your traffic
flow, that is, in order to meet your specific needs. My example rule was
intended for use as an endpoint where I was mainly interested in blocking
all inbound traffic with a very limited number of exceptions with state
being used to allow back in from the outside all return traffic originated
by me, and only me.
It's been something on the order of 6-7 years since I last used ipfw. For
something like 2-3 years after that I used ipfilter. When pf was imported
from OpenBSD and became stable I made the move to pf.
So my recall of specifics related to ipfw is dim at best. Was just hoping
you could pick out some detail which may be of use to you. Your needs may be
different from mine and consequently there is no real one magic "copy this
for plug and play" ruleset. Mine was just one example where I was trying to
illustrate one possibility of utilizing state. And this from a working
ruleset that I used for years.
-Mike
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
