Date: Tue, 03 Feb 2015 12:30:07 +0300 From: Lev Serebryakov <lev@FreeBSD.org> To: Julian Elischer <julian@freebsd.org>, freebsd-ipfw <freebsd-ipfw@freebsd.org>, freebsd-net <freebsd-net@freebsd.org> Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny Message-ID: <54D0951F.2000304@FreeBSD.org> In-Reply-To: <54D06E5C.3090701@freebsd.org> References: <54CFCD45.9070304@FreeBSD.org> <54D06E5C.3090701@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D0951F.2000304>