[RFC][patch] Two new actions: state-allow and state-deny

Lev Serebryakov lev at FreeBSD.org
Tue Feb 3 09:30:20 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03.02.2015 09:44, Julian Elischer wrote:

>> So, stateful firewall with NAT could be rewritten like this:
>> 
>> add 1000 skipto 2000 all from any to any out xmit outIface add
>> 1010 skipto 3000 all from any to any in  recv outIface
>> 
>> add 2000 state-allow from any to any // keep-state is implied add
>> 2010 nat NR from any to any // No "out" here! add 2020 allow all
>> from any to any
>> 
>> add 3000 nat NR from any to any add 3010 check-state // Use
>> dynamic rule based on 2000 as "allow" here
>> 
>> What do you think?
> 
> I understand what you are trying to do.. but part of the usefulness
> of the state runes is that they can be any action, not just allow
> and deny.
  Typically, it is Ok that they are "terminal" actions. And typicaly
you don't need anything non-terminal-now but "allow" in NAT case :)

> record:  (or record-only) it allows the rule to be stored, but the
> action is not performed. on check-state, the rule is performed..
 I think, it hould be option like "record-only" instead of
"keep-state". Problem is, it adds "if" branch for EACH action (in
kernel code). IMHO, it is very prohibitive. I've though about that,
but decide it is too expensive to have "if (!iHaveRecordOnly ||
fromDynamic)" for EACH action, always. It could be done easily, of
course.

> so skipto 2000 ip from me to fred 80 record-only out xmit bge0 
> would do nothing but record the session and on input the session
> packet would skipto 2000
  Nooooo, not "skipto" again :)

> What I would find more useful, is separate state rules for each
> interface. so you could not have the danger of a packet on
> interface A adding a rule that eventually does something unexpected
> on a packet on interface B.
  Still, in case of NAT and, especially, in case of multiple NATs with
"nat global" added, it doesn't solve problem of ugliness of hacks we
need use to add statefullness.

> looking at my own rules I don't seem to have a problem..
  You have "check-state" only once, on entrance, before all NATs, so
it could work only for packets which don't need NAT. And looks like
(correct me if I'm wrong) you don't try to track states of connections
passed through NAT.

- -- 
// Lev Serebryakov AKA Black Lion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJU0JUfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePFCUP/jqRAvX00JUQyEV0hmffmh4w
iTHeK8v56k76VTm2s/Gm2Mjt5EjqXdjKal5eZ6KfQrkPUBHSkmaA+Grig7AoSw81
2XUX2vj/ihkB8fpC7U5enG8UDDn/KV6rEq8nkHfZ0wEzIyGPXPCsC/8kGTotBnZo
oI0JX9uehDmOgqdOL22jeSX3vgrMZu/V7G9ckrEadmSp7yyiPdwEkTqzZsyt8Df4
n6RT7ox0vezpdZDE0Xsx1zNU9iEd1ViT+gEPgSfHYiEyhml1bnv3qF5pPMZEtYEO
/DG6RFfhel6gukrGZ2Yu7tUaGj+QEXXGz5syuxDmIUBzqdHLi9upoX0TbfDH2L3L
KkcVyYdrcyEQwkeZO3gvugGLnNTRJMDOvrfPR8sgcfmWj2kaVYZZiA/SPr/76XqX
ypCAHnaTbytnkOk0k6afjfofSQ8Gc5mPbll9N+uVkS3Ne11kf1uZKIUgsy/5rtw0
59D3Z5OyFJwYscMMjFkt/rAdLlaD2gd5Et/Jk751UO/x49VXdOz/6ErHZWvtg3io
ku1E8W5SRow+EurWVBmIKkbcuCkUW2eaM30o6LYWwkYB8DdG79ihXfYep6Lj3074
1mvuPsWeouBdxbv9ZWu270aD3MmyNE5IL7aaf86XCa2gG4V+dZisw97v4ZRAHenZ
YdcZpExF2wAV3VVAgO74
=tnKG
-----END PGP SIGNATURE-----


More information about the freebsd-ipfw mailing list