Re: [RFC][patch] New keep-state-only option (version 3)
On 2/4/15 5:24 PM, Lev Serebryakov wrote: -- Re-installation of state (with second, third, etc... packet of connection) should update TCP state of state (sorry!), or it will die in 10 seconds. This version seems to be final (apart from name of new option!). It works perfectly on my router with 2 uplink ISPs. can you put it in the code review system so I can annotate and comment on it? ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: [RFC][patch] New keep-state-only option (version 3)
On 2/4/15 6:08 PM, bycn82 wrote: /Cool, But maybe not all people are following this topic, so can you please simplify it by answering below question in order to allow more people to know what is going on here. / /What kind of problem you are facing and how does your patch resolve it? / let me have a go at this: when you write complicated rule sets with state, you start having problems where the state is too broad, or contains things you don't want in the place where you are using it.. sure you want packet/session A to set the state, but you don't want state for session B to trigger there at the same time. this allows you to set a state/action for all future packets in the session without triggering sessions you didn't mean to, or actually doing that action yourself right now. this give you a lot more flexibility in the sets you can create. An example here is combining NAT with session state. You can only have the rule active on one side of the NAT. If you want ot have state on the 'inside' of the NAT then you want outgoing processing to continue on, so that the NAT is then used. However if you try do the check-state on input After the NAT (you need to do NAT on the same 'side' of the NAT for both incoming and outgoing) then you end up having to do various tricks to avoid being diverted into output processing. what you want to do is be able to set a rule that will handle the incoming packets in a way you want but doesn't do the same thing for the outgoing packets. Come to think of it another answer might be the ability to specify different actions for a session for incoming and outgoing, but that would be quite hard to do. at least this way you can specify a rule for input without having to do the same thing on output. there are other drawbackss . like if you have another check-state in the output path, it will still trigger on the packet and do what you didn't expect. but I think this is an improvement. Having said that. I'd REALLY like to have multiple dynamic sets and be able to specify which set I'm looking in. then you could have differnt dynamic rules for NAT'd and unNATed packets, and differnet rules for the same packets as they traverse different interfaces. Lev, I think this is an improvement, but I wonder if we can make it even better. Julian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: [RFC][patch] New keep-state-only option (version 3)
*Cool, But maybe not all people are following this topic, so can you please simplify it by answering below question in order to allow more people to know what is going on here.* *What kind of problem you are facing and how does your patch resolve it?* On 4 February 2015 at 17:24, Lev Serebryakov l...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 19:55, Lev Serebryakov wrote: Ok, allow-state/deny-state was very limited idea. Here is more universal mechanism: new keep-state-only (aliased as record-only) option, which works exactly as keep-state BUT cancel match of rule after state creation. It allows to write stateful + nat firewall as easy as: To work as expected, keep-state-only should not imply check-state in opposite to keep-state. Re-installation of state (with second, third, etc... packet of connection) should update TCP state of state (sorry!), or it will die in 10 seconds. This version seems to be final (apart from name of new option!). It works perfectly on my router with 2 uplink ISPs. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0eVYXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePOD0P/RwpwF9yMUjyAj/KZnphr/0Y aXHM040qIocIUqnxH7T/vwdhm2w3Zciry8hwXp9f+r2bTIe8+tTn8OwaJ0M/Wp1j QBPxW+rjw49hy3rf2eIQbgX7nTwdIZo7YDnT82Kqtje1mImTBR4qdFcSStJac4hE dJsbpzC6raHUuE8h5V5pWPV/m/OQebK3P5CZzBKKpVTMCX3nVsTnff9qf9L1A0Jd q4KYfOv+NJBaB8G6vJhDHjcqtzGfEJBmYL8kOAslYhlUuyYe+iAhyGFbcUBsXwk8 /dqBalUL2iewFaZppszYZ0rTpVOfA4fOV0ECbVmpcw36uocrC2iOEpBl0WRIy+TM HYIMkIeubF9IT24CwMwiriONpppl8MGynCmL9hyMgu+HiuvHZ/C/vYcVV9/DHFGB iKkNe9QjX34anP6qVvEvHHmuv26PO7eq7hkdK2PZNlA9dwwNHehN8xG3DxB9N8gG MPRGtM8yH/C/FXpqKmHoqj6shMGQCSfmZKPfJ0D49Rze8tSjo7kZaSmaELJAjmsc xLv5umEAg7gym54bMhv8As2lXHnyeDp3uJz6glM72cmtBM5/n8N7NLk6Xga+8eM3 cZ122dgOqzGpts9TqCGWmTRW+f2Y8hLukzIjOLdzlqLPfQmXVn9pOWmqo9OKHdvD we0uYcnte/iSltopkVuG =muco -END PGP SIGNATURE- ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
