Re: [RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 08:13, Julian Elischer wrote: > yes I think "keep-state" should be deprecated and replaced or > supplemented by 'save_state' that does NOT do an implicit > 'check-state'.. I don't know whose idea that was but it's just > wrong. (if the state exists, maybe just replace it..) Update, not replace :) See my Version-3 patch for "record-state" :) - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0eTUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePoS0P/iCMeTo+fFA4iGwe/8FnlF+y 899fomt4tzOBppxg1r5/xx11OMB9DJ6VG1z8+61gzIg1jgxvAIBTBGz5oxIgyfv5 mtbEbfhsxsABYTASjwIQymxR1zvLCbyd7fWgDRhM8YJYEy/akWNzOwtbokrkK1Ww 3j2IODup3onYr5LhwoQZGPdtmIyH10rnEcs49IWUs1ZweWlJx7XRQOGBAepTQRx9 bh/D0owV1j9BBzyqd5n54aXiQpMKMIdOihmNOOUYhl0B3GksacWguV7Keabbv0Dh Nnk3g/GrBYJPdmF0JqkocjrGxSuWAwBXfdXg3SoG8l1dPqaDg8UNVXq7VthS7FKO 8jyoRXaptbcrTjgG0SHdfnSzbhpLj78/PdGi1VvJwrvjnK2MNb6dZ2PE3E88ScgM f7OIOef9GyLwgAPqn6TJeiC7Oddvq+vL1vEigqLMJscJ4ErwqX8RVidbkYdNmKCf HYSd9mSJgkAMUH7q2U5PCRY9Ay6BOkuGHEqvMHGFClqBWb81RTyT8ZR+BL+JeqRr QNilMWvUXJSGEcvMYijKiv2EVDB6by3sY2SK9KLa93H0jY1nR3XPpilpyLcHLzN9 5aVknqR2/TzFDS1BiSEg/wYipyqjgIyHTqqxj0Vd0pnZMSw3AqdrOSLz8mHJzXKp 3J8Y7Lw7fuM1N8Doq2Md =/M0i -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"
[RFC][patch] New "keep-state-only" option (version 3)
-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-
Index: sbin/ipfw/ipfw.8
===
--- sbin/ipfw/ipfw.8(revision 278151)
+++ sbin/ipfw/ipfw.8(working copy)
@@ -166,7 +166,8 @@
depending on how the kernel is configured.
.Pp
If the ruleset includes one or more rules with the
-.Cm keep-state
+.Cm keep-state ,
+.Cm keep-state-only
or
.Cm limit
option,
@@ -582,7 +583,8 @@
packet delivery.
.Pp
Note: this condition is checked before any other condition, including
-ones such as keep-state or check-state which might have side effects.
+ones such as keep-state, keep-stat-only or check-state which might have
+side effects.
.It Cm log Op Cm logamount Ar number
Packets matching a rule with the
.Cm log
@@ -1583,6 +1585,18 @@
.Xr sysctl 8
variables), and the lifetime is refreshed every time a matching
packet is found.
+.It Cm keep-state-only | record-only
+Upon a match, the firewall will create a dynamic rule as if
+.Cm keep-state
+was specified, but after that match is cancelled and the search
+continues with the next rule.
+On dynamic rule match action, specified in this rule,
+performed as if rule contains
+.Cm keep-state .
+This option doesn't act as
+.Cm check-state
+in contrast to
+.Cm keep-state .
.It Cm layer2
Matches only layer2 packets, i.e., those passed to
.Nm
Index: sbin/ipfw/ipfw2.c
===
--- sbin/ipfw/ipfw2.c (revision 278151)
+++ sbin/ipfw/ipfw2.c (working copy)
@@ -292,6 +292,8 @@
{ "in", TOK_IN },
{ "limit", TOK_LIMIT },
{ "keep-state", TOK_KEEPSTATE },
+ { "record-state", TOK_STATE_ONLY },
+ { "keep-state-only",TOK_STATE_ONLY },
{ "bridged",TOK_LAYER2 },
{ "layer2", TOK_LAYER2 },
{ "out",TOK_OUT },
@@ -1993,6 +1995,10 @@
bprintf(bp, " keep-state");
break;
+ case O_STATE_ONLY:
+ bprintf(bp, " keep-state-only");
+ break;
+
case O_LIMIT: {
struct _s_x *p = limit_masks;
ipfw_insn_limit *c = (ipfw_insn_limit *)cmd;
@@ -4335,14 +4341,16 @@
break;
case TOK_KEEPSTATE:
+ case TOK_STATE_ONLY:
if (open_par)
- errx(EX_USAGE, "keep-state cannot be part "
+ errx(EX_USAGE, "keep-state or keep-state-only
cannot be part "
"of an or block");
if (have_state)
errx(EX_USAGE, "only one of keep-state "
"and limit is allowed");
have_state = cmd;
- fill_cmd(cmd, O_KEEP_STATE, 0, 0);
+ fill_cmd(cmd, i == TOK_KEEPSTATE ?
+ O_KEEP_STATE : O_STATE_ONLY, 0, 0);
break;
case TOK_LIMIT: {
@@ -4580,12 +4588,13 @@
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 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"
Re: [RFC][patch] New "keep-state-only" option
On 4/02/2015 4:38 PM, Julian Elischer wrote: > On 2/4/15 1:32 PM, Julian Elischer wrote: >> On 2/4/15 12:13 AM, Lev Serebryakov wrote: >>> >>> And variants with multiple NATs and "nat global" becomes as easy as >>> this, too! No stupid "skipto", no "keep-state" at "incoming from local >>> network" parts of firewall, nothing! >>> >>> P.S. I HATE this "all any to any" part! >> can we get rid of it? (implied).. or just add "everything" >> also I am not sure about "keep-state-only".. >> how about 'set-state'? or record-state as I started with.. > or record-session.. (state always annoyed me) > >> >> record-state seems more intuitive, while record-session suggests a wider scope involving session negotiation. Regards, Dewayne. ___ 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 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] Two new actions: state-allow and state-deny
On 2/4/15 5:22 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 08:13, Julian Elischer wrote: yes I think "keep-state" should be deprecated and replaced or supplemented by 'save_state' that does NOT do an implicit 'check-state'.. I don't know whose idea that was but it's just wrong. (if the state exists, maybe just replace it..) Update, not replace :) See my Version-3 patch for "record-state" :) I meant a function that acts like 'keep-state' except it does not do a 'check-state'. Im suggesting adding yet-another command. a 'fixed' keep-state. I sort of know why they did it.. so that if the state for that session already exists, the original state rule is used and not the new rule. but ..it fires on other packets as well as the one you are working with. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0eTUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePoS0P/iCMeTo+fFA4iGwe/8FnlF+y 899fomt4tzOBppxg1r5/xx11OMB9DJ6VG1z8+61gzIg1jgxvAIBTBGz5oxIgyfv5 mtbEbfhsxsABYTASjwIQymxR1zvLCbyd7fWgDRhM8YJYEy/akWNzOwtbokrkK1Ww 3j2IODup3onYr5LhwoQZGPdtmIyH10rnEcs49IWUs1ZweWlJx7XRQOGBAepTQRx9 bh/D0owV1j9BBzyqd5n54aXiQpMKMIdOihmNOOUYhl0B3GksacWguV7Keabbv0Dh Nnk3g/GrBYJPdmF0JqkocjrGxSuWAwBXfdXg3SoG8l1dPqaDg8UNVXq7VthS7FKO 8jyoRXaptbcrTjgG0SHdfnSzbhpLj78/PdGi1VvJwrvjnK2MNb6dZ2PE3E88ScgM f7OIOef9GyLwgAPqn6TJeiC7Oddvq+vL1vEigqLMJscJ4ErwqX8RVidbkYdNmKCf HYSd9mSJgkAMUH7q2U5PCRY9Ay6BOkuGHEqvMHGFClqBWb81RTyT8ZR+BL+JeqRr QNilMWvUXJSGEcvMYijKiv2EVDB6by3sY2SK9KLa93H0jY1nR3XPpilpyLcHLzN9 5aVknqR2/TzFDS1BiSEg/wYipyqjgIyHTqqxj0Vd0pnZMSw3AqdrOSLz8mHJzXKp 3J8Y7Lw7fuM1N8Doq2Md =/M0i -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"
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] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 14:11, Julian Elischer wrote: > On 2/4/15 5:22 PM, Lev Serebryakov wrote: On 04.02.2015 08:13, > Julian Elischer wrote: > yes I think "keep-state" should be deprecated and replaced or supplemented by 'save_state' that does NOT do an implicit 'check-state'.. I don't know whose idea that was but it's just wrong. (if the state exists, maybe just replace it..) > Update, not replace :) See my Version-3 patch for "record-state" > :) I meant a function that acts like 'keep-state' except it does > not do a 'check-state'. Im suggesting adding yet-another command. a > 'fixed' keep-state. Yep. Maybe, additional option? Which will work only on user level and force to skip generation of O_PROBE_STATE? Now on KERNEL level nothing force this check, it is additional opcode, added by user-level "compiler". Only thing we need to make it work properly is in my last patch for "record-state": add TCP state propagation to "install_state" function to make it able to update existing state properly. and after that you don't need any additional opcodes for "keep-but-not-check-state" command/option, it will be user-level change. > I sort of know why they did it.. so that if the state for that > session already exists, the original state rule is used and not the > new rule. but ..it fires on other packets as well as the one you > are working with. Yep, because O_PROBE_STATE is FIRST opcode always. It is matter of compilation. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0gOIXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP/1sQAKMgZyk3BVCXB8Q+Rmvy/D0K YhPICBbPqUWHw35HfXG0hgw66pa/SX0G68HO2LoxurbxFtu3pdsKA3X8ok4J3Yvb 374MPQcUYFxoUmvjjWUpNMGUBBm72TPk61cjUdsWWJoYWrLJmM0UMJ2wJREvS2D6 s0hUuFGBb/OaTW8aHWY2gAwViPDxR2gQmX8Pw6XpZLxR3ZyNcMTnx78jGn+8jykM tLxmLjlOSAw4XfsbkiG6X7CmkgyFhcN/B6cpRNB8qsLSmG6rzBup6JrAcFYRq/63 LUj8Z0azwJoHqeLBKZ7RfcfqbB9PMdMTaufBPxQVclQntERkN4nEacT4LSRd1aoL 2zEKMV+PN8X4sL3h73laURLq5lHOVuJsG73YGR1n/IPtlkeeLu1zOADjPRd/0ZY+ kOWzvE00RGhb1mt2LNpL9qZQ8oIcf0r3pYuZKmV0vT7BnQ/Pw4lMjcPyHPSJyFgR yn2fslDvytg8e/iPvHuOm6h8t6Um3bAbV2LrW4fHSgbhMPGt/nzwuRicMoj6o+Fx r3q+ITM54QbodBZuS0Ie7IvCNZIfYwwp27GS1lZ8lEv1lYy4kVW9B3AOZzows5XW YWjVz4xzYd3qaTQyoNij9NFJYVx52IXoAP23PFPDhbr1OFhomGVXQCgu/KS3JHOQ kR5C1h4iKmkjLUCmDC/P =sqjh -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"
Re: [RFC][patch] Two new actions: state-allow and state-deny
On Wed, 4 Feb 2015 19:121:46 +, Julian Elischer wrote: > On 2/4/15 5:22 PM, Lev Serebryakov wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On 04.02.2015 08:13, Julian Elischer wrote: > > > > > yes I think "keep-state" should be deprecated and replaced or > > > supplemented by 'save_state' that does NOT do an implicit > > > 'check-state'.. I don't know whose idea that was but it's just > > > wrong. (if the state exists, maybe just replace it..) > >Update, not replace :) > >See my Version-3 patch for "record-state" :) > I meant a function that acts like 'keep-state' except it does not do a > 'check-state'. > Im suggesting adding yet-another command. a 'fixed' keep-state. > > I sort of know why they did it.. so that if the state for that > session already exists, the original state rule is used and not the > new rule. but ..it fires on other packets as well as the one you are > working with. I don't get this .. we're always working on just one packet at any time, either inbound or outbound (to kernel), so how can check_state (or the check also on keep-state) apply to any other packets than that one? I've seen examples that run keep-state on the same packet both before and after NAT, ie state on both the internal and external addresses, which is even more confusing and surely inefficient too. I'm not sure that everyone realises that it's the first check-state or keep-state rule _encountered_ - ie not skipped around - that matters. A good, definitive tutorial on how to best handle stateful, NAT'd rules would be useful, because there are a few different theories in the wild. Personally I only run stateful on a few types of session, and then always using the internal addresses, but that's just one of the ways .. but doing _everything_ statefully seems to be the Holy Grail to some. cheers, Ian ___ 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] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04.02.2015 15:34, Ian Smith wrote:
> I don't get this .. we're always working on just one packet at any
> time, either inbound or outbound (to kernel), so how can
> check_state (or the check also on keep-state) apply to any other
> packets than that one?
Simply enough: assume packet goes from internal network ("in recv
em0", say) to external one, ("out xmit em1"). It passes firewall
twice, really. In ip_input() (it is matched by "in") and ip_output()
(it is matched by "out").
Say, we have "keep-state" for this packet when it is "in" as last
action, something like "allow keep-state" to have this state to check
answer packet "in recv em1" (note, "em1" here) appropriately.
And in "out" section we could have OTHER "keep-state" rule, for
locally originated packets (which never pass through as "in" ones). Of
course, this, second, "keep-state" is equipped with additional
conditions like "src-ip me".
Now, our transit packet creates state in "in" section and is passed
to "out" section. And it triggers this state on "src-ip me keep-state"
rule! It doesn't belong to this rule! But doesn't pass conditions of
this rule! It SHOULD NOT BE AFFECTED by this rule, match failed, try
next one! But -BANG-! "keep-state" has implicit UNCONDITIONAL
"check-state"! So, we need additional stupid skipto like this:
XXX skipto ZZZ not src-ip me
YYY allow src-ip me keep-state
ZZZ nat 1 // out
To me, it is stupid, contra-intuitive, non-orthogonal and bad design.
I think, there is THREE DIFFERENT things:
(1) Creation/updating of state, with normal condition checks on packet.
(2) Checking packet against state table, updating state, performing
action (if appropriate state is found, of course).
(3) Performing action WHEN state is created (not checked!)
Now ipfw has very tangled way to do this. We have:
(A) (2) + (1) + (3) (in this order, please, note that condition
checks are done in (1), not BEFORE this chain). It is keep-state.
(B) (2). It is check-state
(c) (3). It is stateless rule.
That's all! You could not do (1) without (2). You could not do
conditional (1). You could not do (1) but not (3). Nothing!
And if "conditional (2)" may be too much, but only possible to go to
(1) is via (2) and inevitable (3) after that is too much, IMHO! It is
very obscure behavior!
To be honest, I want add not only "keep-state-only" (pure (1)), but,
also have "keep-state-do-action-no-check" to have (1) + (3) without (2).
- --
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJU0hiMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePd60P/iTr55i4uyLfa7cf/TH9ypdt
S9iP23qGZDPo+YzjVfmcyBNWbYJ2eNfkve9DhYHoizpacqHeepnWfMxNPdSf0kLI
lZ0qYt/EtwTDCOoSx+wE/c1ywzvHUKO7k631GS/EpRbUwli5yEZnJEFwJPlEJ8WY
A3uBtPxBAn3CEiS7ps91Da260Qt3xgw4Sv99YOzY7k2etUOsj8r2EEkLG8gsH96V
Pk4udb17Kc0WygwNN7OaI1mxXaoKkd6NzZM4W0WvWy5fKgD/Rhep5hD4/oFixfsJ
HKxjYjUDrzc6/elL5GW1+OwzQ08+KziriRqBT2QMOJnso9a1yQc/5jvO1C4zol9Y
wF3ZgcMIAJKBmOdkWHPMfrhNYMutI8gPsKH063BRkHFTtTQb7yL8bysLYE1P23lM
hzl3ubZtcas7Z5kBpsAL2L0xXLReMCCTSULv0oQDitb6H4z3eUeN5iq2Sk6b0uwB
J6mZiHCYU48KU0ST4/UAnZFYX4mUFTiIfP2KzekdZ+BUNdGgdVr177EJChZxBL4M
x/In6x944pwRxCExFa10OSMzQqdOJ+IQEfS1LfG+l/A4X7Rjx87Gbb4A/3ePkkdA
HoZLACmRfFGxmWILZa8EtldUvDsOjXs+Q08rpvp2So0szcM0N5XIixDbnLEvCqFu
xn6GOWuyaJVzZlpllCV0
=ALXi
-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"
Re: [RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 16:03, Lev Serebryakov wrote: > To be honest, I want add not only "keep-state-only" (pure (1)), > but, also have "keep-state-do-action-no-check" to have (1) + (3) > without (2). Ideally, here should not be implicit "check-state" at all, and should be two options to rule: (1) keep-state (2) skip-immediate-action So, current "keep-state" becomes two-rules: check-state all from any to any keep-state And all other variants are possible too, like keep-state skip-action and meaningless, but still possible, skip-immediate-action It is hard to add now in backward-compatible way, though. But may be... May be... I should think! It looks like doable on second glance, and better (more flexible & orthogonal) that my current proposal! - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0hrdXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePGFcP/0CpmLVadnVjQqC+PLQVpT4E cqLy5RfE4D587JeaXfoDher7J/WJj02NKJWkuhZqkvuZAVvFx5xiyl63X9yR1ASR a8rHGkM9pa4wbQ9XA2YKlhsaVntQtmmk1/qyp9AZecX/aZl6taWualeRCPGgNSvC lP6JdUCTelUIjlGwvsKI4Xu9ljuV59PaYh3SxLXxQSuyr5CA1ayRjT5e6Mp7SLPk gfy38Cq7PmrwrQAtkYfcP8K9fYTpnHaKqXYKpELSIqbpKGUcB0AnloXg9u2fJbmD Ux8lf0MvpDOiw0UfcHaypluLzU0/vuWE9EwyXe4p6GbdWjd9YXwgkbMsCWcR5lbT KJrAo0Jk2//blLFtKNDSLHb3JpKjSQkVRE/dhNOr066m682xnloPxFPE1p1e79P8 9D4Yi/ii2CGR15tP9keNjnDEOvO5JSSD+kHH/elUyuHye++UjKKNJoDCp5JIopFr SJ7NHYyVhlMmIMWIQeXUIRoNxblv9C5C9G2k7nBMlaxWN8VG0AKIerRyHTrEtwzt 0M9Tb6Et7dXULvqR0U+PgXvOLDo+DmmYf5cZiUCsVnLba0UwcWt7i2qWsA9KmQEE ZqTaVz8cJSkHybQLqlGtIwMfWgh7s6XSAjaPgk0OviDNCwTs9Ry/6QRPpCnkcC5p wsN8ML5mL59HqlkIvTxU =gWCG -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"
Re: [RFC][patch] Two new actions: state-allow and state-deny
The possible issue is is that once NAT changes the IP address and possibly the port number, state tracking can no longer be applied. AKA, the packet headers before the NAT is different than the packet headers after. This is why NAT needs to track the state instead of ipfw. ___ 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] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 18:13, Jason Lewis wrote: > The possible issue is is that once NAT changes the IP address and > possibly the port number, state tracking can no longer be applied. > AKA, the packet headers before the NAT is different than the > packet headers after. This is why NAT needs to track the state > instead of ipfw. If you create state and check state on proper "ends" of NAT (for example, create state for connection BEFORE out-NAT, with internal addresses, and check it AFTER in-NAT, with internal addresses again), it will work. But now, when state creation is terminal action AND state checking in one box, it is hard to implement and leads to very non-intuitive rule sets. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0jiVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTnQP/2kxqyTxUSa3RBLBsoq58iL4 IeGarQ7PrTVVaBTEVzhabU0yPuORpMqrwf47nImAZQWHcQP7UUjO+VjjqDthwwe8 S3CElbPFW86HmYLB7Nz1Lhg7n0eaKG6xxDO5um/b3cWuK7B3DiU+9oW7OHICF0Xa mk5Z9koVuAS3yuvT6PecSRgziV6HgxEKgYgNCgN+JmXWlL/H8kYUuYKBQTv1snkw hcRLKrRp31KavH8CRiTf6uBCozS4URvr6xRSfrkjcuU9LUlvHcI6jBCm7yOAEeDH HkcU5g5mNSK0vdJXZVmtveFADs8RrtAtovxt4FQZCjYPBhCDMRvM9IPQX8eK8tKX 8efJHb6DPIZQs+AeEhL1jeNJTu/UJRUag65Aua7TXq7jcopOMHM85aNMs6FzyqeG eT5Epc+oZ0Zbi0RAZzqvUeQSnARPE4tGddoOK5z5YMbF0jSiHM5ftfYncOp8YvDE uJMQAHOU4CHfuK/knzNkZ4VoD3+i+/fIiR4knNCLCe1wOvY9QmI+3iyk6JGZ4GJ9 vc7W+XCSnfuhFq5+o/8Lr+50z2qpmkJVaWoRW4DItWiHrWbx6dngL2aY8+e7TjEk 24rRQb16uYC6w3dUkNiKHMtUEaN+Zzju186jbQZpPjX6Rz4/9i2DJ6qYiZDWV28x e5TUOek2WeiROK+VvF/2 =XfPm -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"
[Differential] [Request, 190 lines] D1776: New options for ipfw - record-state, set-limit and skip-immediate-action - for simpler rulesets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Looks like, there is no "freebsd-ipfw" mailing list from Phabricator's point of view. Please, review & comment! https://reviews.freebsd.org/D1776 - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0lSzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePah4QAIv6YNwQubxEIyqE8GqZlbhm 6fLnRNWI35QHEFtfdlqrtFj5TcArY3o529hQXj6Fjhmu/XQyonH7IBpshiXBUXs/ GIGHaQqXaIsZtiAPhhqpBBta+yp3q8oDg541uDYgRz0IYIrmEPsVIoCDiwW+aWec SmSDmdJyvDy+mAOUujSM47j7dcvirKdIOthJWi3Wjnrtjpd/wEfyduRAft30zi04 88ELKxD9t8t5KvHmPer2FLGRAg7wY1OWUWHxeBCrIkAgKg6anajfUPyIqbomJoI4 IQwJN5GRqJDVvR/3c7W4ifHcNKa7FNFvpKUDwTlBJqWphWIMzVtuoDWZ2aCJlQ5E nwmNuLuzIPGtyFDg1oCMJxx5YWfXQzbYaCECmE9jveg3PU6QpcgbHb3FzJOXR/kA Bt9nkodRldULAXSVfigDk6ZzTq5XgqutPjkgpBHAXGmIMsPGfJU/t18wmR/Hkrhq 8esEpGD9lLkZty/sLG7k5fqeeJI6PZPieui+m2Jy31phUWg7O3FJmqH7Fm2BkeRu FvAR40wd5y8pt6odtKsb9M3kpCoNu5vrigPCPDL92Q+V+lWLsV4eJLoptKnYYTdc pePqP+wqYOH/IAM8XQUFsxBOuKD5goUcNdPDh57pmCDJR2zgfvEmywSez9KuS+Pa 3MwtCcW/PGzjAivBx0iE =Bedo -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"
does "nat redirect_port tcp" works for you on -CURRENT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have such rules in my firewall: nat 9 config redirect_port tcp 192.168.134.2:16881 16881 redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp 192.168.134.2:22 2 nat 1 config ip $EXT_IP same_ports ... // Packets from outer world 11040 nat 9 // Redirection? 11050 nat 1 dst-ip $EXT_IP // De-NAT what should be de-NATed (not redirected by previous) 11060 check-state 11070 skipto 3 // Allowed local services - common block ... ... 30030 allow proto tcp dst-ip 192.168.134.2 dst-port 22 setup keep-state 30040 allow proto tcp dst-ip 192.168.134.2 dst-port 16881 setup keep-state 30050 allow proto udp dst-ip 192.168.134.2 dst-port 16881 keep-state ... And looks like TCP redirection doesn't work. Counters on rules 30030 and 30040 is strictly zero and "ssh -p 2 $EXT_IP" (from external host) doesn't work. Rule 30050 (udp one) HAS counters increased, but what is REALLY strange, is that 11040 and 11050 (two NAT actions) always have SAME counters, as if 11040 never change destination address. Nut 30050 sees some packets! Is "nat redirect_port tcp" broken in -CURRENT or do I do something wrong? - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0pohXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePjNkP/3msSEuRm6RWuGGVqIddHzki k2oh5YfbjfXC6hP4XumouqHojbHoHfNqv6yOet31xFwscnX71Q7LVSTF95jhbu9J jJrF2PDkPh+d6XagtuLaAHBvG3PRS61vgW9kl00/IiiemPfA/r10vcXz1TixdLgB bI/N0OFQyz9YXwWWEwZNywAOLaUTYD1FM2F5FtbwGvedlhBcmC08h1D5M1Vk2mF5 P/2ZocAECUeRPW5/JRg6kcnA3nJ8CVJr08I1IqQEsaQifRAOFfYcVSdb9DbK5Hms z6nVaJSwi6D1QtxR4x3BNoqGD8o3oc5YWW8obsV6uYzxfZcew2OoyiRgTMDuoBho 73q6WmUlvlvFB1PCOCGr8YxzHPpQZ7KP8NMKoSM8CiAT0/n5qY9CJGOxcf2Q4EEv tErw/TkjAXmzxGDj0ZZBjjvWE7kIhSk9HgXfzF3XL3FasmcV5Iu+JeSswlPtpHyD RCfB84rUcjmldpGZVs9OXD3+jJpY2JaXNrDmdM7elVr9d/CvM1IDkm62N9b9Pqjr uE4VKyipVrbsb06INchz9Gg5D1LhTbBCWoB6mo/5F1dYBkpSqezVUMsibcKvLbeR 9cBkL+iQif1Q8TmfIMYBwbqcfIx6MhbOxhtAiHR3QECc1IJ6Vn3/hrcVzB/PXc4Y SQU7uy3TpJH320nN1BDV =aAlm -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"
Re: does "nat redirect_port tcp" works for you on -CURRENT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05.02.2015 01:16, Lev Serebryakov wrote: > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > 192.168.134.2:22 2 Also, if I add "log" to this config: nat 9 config log redirect_port tcp 192.168.134.2:16881 16881 redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp 192.168.134.2:22 2 I could not print this log: # ipfw nat 9 show log ipfw: unknown redir mode ipfw nat 9 config log# Configuration printing is Ok: # ipfw nat 9 show config ipfw nat 9 config log redirect_port tcp 192.168.134.2:16881 16881 redirect_port udp 192.168.134.2:16881 16881 redirect_port tcp 192.168.134.2:22 2 # - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0ptEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePphIQALKqUuR7wGZGlJaR58arzYZi boLuUxCSoM98UBO58egLeEgn7CKVxt34JRH6OwjDh18KeocfYr92LoYCpt6324dM rjQqy4PdYda91aW+46qUFFY1n3i55AB+WfLDdmUNivqGn+ouKnSHdoFMknvG+bnC n1DZIEiUpbE5ZnlA6XJ3nZUpmmKVTpHBWemEzF/Vn3f8A9ShJlI3fmK3+eh+SH59 B6k4IgcGryDsskCBuRTam+dYq89+a0wSVyzcrNiYLxikPy+wE2bCwY8tE63I5khZ 7MAuSVlgaOq+CvJmKRQ+522h3H5w6eco/wQokq1IyhpBeLNwI55BfY5jZdll9/M8 c6d5yho85VzXbNbTi2XXSWAmi9xYw6Pag4dA8iaLe2Mdoh8klgtOKBVo9uNw7ywX WS7/NyhlmMvJffStdO2t88awEV5NNE5lYeCmCstK3zZ+m7feKDynhHrUqOoXaZux 7tylx0J0rihdULZH1PyceO6y9aGRKfdoes0oiUc3ovumUunmFrTUdkEgodTG2nEo CPSlvy5rthL634b1NSBIrdHPGYo+6IQR3s4MaTs/RvdIVQHoZrl4XtKz8h904Fl4 MuYCfNI4E7I/AV6n3rbidQvfgosu4+wtR+4tZ8iV7gTLNZEZ6DiyXn8Ab3sNKuLC LjOfhudWDkmfumCqIkNE =hZrV -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"
Re: does "nat redirect_port tcp" works for you on -CURRENT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05.02.2015 01:16, Lev Serebryakov wrote: > I have such rules in my firewall: > > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > 192.168.134.2:22 2 > > nat 1 config ip $EXT_IP same_ports One more datapoint: if I merge this to one NAT (and change rules accordingly), redirect work as expected. But I have TWO different NATs in full config (for two ISPs) and don't want to duplicate all redirection specifications, but want to use third "common" NAT config. And such usage is shown in ipfw(8)! - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0qfhXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePtxMQAMg/YeLuNTP4KzKAGb8Z0AXc RLMdopJaZ81R5f4LnWtcQR1n0hzdLRhsmFvPLuHUdB6RgFbJ+TreMZq4h5IMLivy Wig9Uljhjkd6nS415ca4pQSrd9fzymI69WTLq/WSHwgxv6ngeT1x97cNh20R9VuD 3tPxj70Lf5IhtHB4MePpb3mh+iaLuaB9pizoP57M7YghN5qjvgXnaDRPamWiCfJl moUAXL1OQ0wInz1G9Z08nXJQz33mcJWlBNlPUc6n58nGjJGrgtNQL7sNCbs9yvVg +3+bHVH1e6v0BVuDKfEpYPP9KjCCLPWQvh7IgMpjur4fUBpe2TGVo+PS5i8ndakF KGvhmqJYsENuyh4GbiyQPN6kbDXXWl/PnUDKmtRHAdFMPLYOPkrgH4WJgHOU2zuR +iOmT5pmhG/9lb8yrNy8gmWgoj8XUvA/RlCHNtqzKVX9A6cFk+Tg5XMYSGbFlWYL h/O72zcSc7HQ/bsgj2sDT8ohfyIRCo9PtQPXtC2t0rdrDRQllCGNRALnUk8C0K2+ 4cYN4R3fIEjIBXAl6eCPlBDJEzS+WnXNNea1qIlW54vP5JmtQ7AMaSl0teUxNInU 8V4OUl+R9XMG456Ri370abfFHIr8PN63G9FhfCjWAPzyAYLR48HooGcCZN9Zzz4L vYxM8Xo9xKtuV9G9E8f0 =GIA1 -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"
Re: does "nat redirect_port tcp" works for you on -CURRENT?
On Thu, 5 Feb 2015 02:14:41 +0300, Lev Serebryakov wrote: > On 05.02.2015 01:16, Lev Serebryakov wrote: > > > I have such rules in my firewall: > > > > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > > 192.168.134.2:22 2 > > > > nat 1 config ip $EXT_IP same_ports > One more datapoint: if I merge this to one NAT (and change rules > accordingly), redirect work as expected. > > But I have TWO different NATs in full config (for two ISPs) and don't > want to duplicate all redirection specifications, but want to use > third "common" NAT config. And such usage is shown in ipfw(8)! Just curious .. what's your value of net.inet.ip.fw.one_pass? And does all of this really need cross-posting to net@ as well as ipfw@? cheers, Ian ___ 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"
