[RFC][patch] New "keep-state-only" option
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
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:
nat 1 config if outIface
1000 skipto 2000 in
skipto 3000 out
deny all from any to any // Safeguard
2000 skipto 4000 recv inIface
skipto 6000 recv outIface
deny all from any to any // Safeguard
3000 skipto 5000 xmit inIface
skipto 7000 xmit outIface
deny all from any to any // Safeguard
4000 // For sake of simplicity!
// Real firewall will have some checks about local network here
allow all from any to any
deny all from any to any // Safeguard
5000 // For sake of simplicity!
// Real firewall will have some checks about local network here
allow all from any to any
deny all from any to any // Safeguard
6000 deny all not dst-ip $EXT_IP
nat 1 all from any to any
// All enabled with "keep-state-only" at block 7000 before NAT
check-state all from any to any
// Here could be accept rules for our servers or servers in DMZ
// Disable everything else
deny all from any to any
7000 // Here goes rules which could DISABLE outbound external traffic
// Create state for "check-state" at block 6000 and fallthrough
allow keep-state-only
allow src-ip $EXT_IP // Save NAT some work
nat 1 all from any to any
allow all from any to any
deny all from any to any // Safeguard
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!
- --
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJU0POaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePR+gP/1Oxi+h7pi0UlnqfrKyfHJRS
FUbrMNeR9NATnTwxIK1UxNT1kF3m7wiwnFlgwW7rwLtTviFB1wK/pfd38l2h4t/w
qUbtyK4PFMCq8I6wAJIB0qUl3C/mN1rwc+LSJJyFM07R52snoQs6FvkIYkCz0fOy
Cak1f/P+scc21IRhFvYJXMMDO/1Y1nkxZk/HdHbn1GELpTXuHugvL1T9hHl98sqO
HKlHnvtqAVlyZn9Sv3uC9nsyjFA2sdOCtb67UGnPDV3CIs4Jwj5CSst5jbz13qFG
aXF8ZSm0coPJMUjH1PSogZM9Xiq23yZ47V0mesBxQsHL24548jM/wKcsR3buDjP7
NJ2rqo2OBCzTu6VCK2oIY5j9A6vq1mu8+/eBs5jF4C2k0xHiw53Okou7zOCA0gJ+
z+VGZvD3la/+tFjacty7Ra7LLNA8kNCnRa0QML7LOJ1/99a4l3Z/uGFxy5zYnk7d
p27Y85CAhTJQjkYZSGAiFD5SE4XxRqtSJ9OL89w7vLxoHqW0rqwi+DVrr9uvXQZS
8Z5G5iQARG4ygXuKsl6MlwChCXa3ucbOs41lorrug94cuVCwGg859zBZY3dpQsKz
XIhtVQS21wPLxXywzIc678ar4uKVWNiaRWg+k57O7375gAszvqujRuTEcfHRf/T+
gHJJZt8Tc+en4bw8XItY
=wOAJ
-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,
@@ -180,7 +181,8 @@
Dynamic rules, which have a limited lifetime, are checked
at the first occurrence of a
.Cm check-state ,
-.Cm keep-state
+.Cm keep-state ,
+.Cm keep-state-only
or
.Cm limit
rule, and are typically used to open the firewall on-demand to
@@ -582,7 +584,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
@@ -748,7 +751,8 @@
If no
.Cm check-state
rule is found, the dynamic ruleset is checked at the first
-.Cm keep-state
+.Cm keep-state ,
+.Cm keep-state-only ,
or
.Cm limit
rule.
@@ -1583,6 +1587,14 @@
.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 .
.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 },
Re: [RFC][patch] New "keep-state-only" option
On 2/4/15 12:13 AM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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: nat 1 config if outIface 1000 skipto 2000 in skipto 3000 out deny all from any to any // Safeguard 2000 skipto 4000 recv inIface skipto 6000 recv outIface deny all from any to any // Safeguard 3000 skipto 5000 xmit inIface skipto 7000 xmit outIface deny all from any to any // Safeguard 4000 // For sake of simplicity! // Real firewall will have some checks about local network here allow all from any to any deny all from any to any // Safeguard 5000 // For sake of simplicity! // Real firewall will have some checks about local network here allow all from any to any deny all from any to any // Safeguard 6000 deny all not dst-ip $EXT_IP nat 1 all from any to any // All enabled with "keep-state-only" at block 7000 before NAT check-state all from any to any // Here could be accept rules for our servers or servers in DMZ // Disable everything else deny all from any to any 7000 // Here goes rules which could DISABLE outbound external traffic // Create state for "check-state" at block 6000 and fallthrough allow keep-state-only allow src-ip $EXT_IP // Save NAT some work nat 1 all from any to any allow all from any to any deny all from any to any // Safeguard 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.. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0POaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePR+gP/1Oxi+h7pi0UlnqfrKyfHJRS FUbrMNeR9NATnTwxIK1UxNT1kF3m7wiwnFlgwW7rwLtTviFB1wK/pfd38l2h4t/w qUbtyK4PFMCq8I6wAJIB0qUl3C/mN1rwc+LSJJyFM07R52snoQs6FvkIYkCz0fOy Cak1f/P+scc21IRhFvYJXMMDO/1Y1nkxZk/HdHbn1GELpTXuHugvL1T9hHl98sqO HKlHnvtqAVlyZn9Sv3uC9nsyjFA2sdOCtb67UGnPDV3CIs4Jwj5CSst5jbz13qFG aXF8ZSm0coPJMUjH1PSogZM9Xiq23yZ47V0mesBxQsHL24548jM/wKcsR3buDjP7 NJ2rqo2OBCzTu6VCK2oIY5j9A6vq1mu8+/eBs5jF4C2k0xHiw53Okou7zOCA0gJ+ z+VGZvD3la/+tFjacty7Ra7LLNA8kNCnRa0QML7LOJ1/99a4l3Z/uGFxy5zYnk7d p27Y85CAhTJQjkYZSGAiFD5SE4XxRqtSJ9OL89w7vLxoHqW0rqwi+DVrr9uvXQZS 8Z5G5iQARG4ygXuKsl6MlwChCXa3ucbOs41lorrug94cuVCwGg859zBZY3dpQsKz XIhtVQS21wPLxXywzIc678ar4uKVWNiaRWg+k57O7375gAszvqujRuTEcfHRf/T+ gHJJZt8Tc+en4bw8XItY =wOAJ -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] New "keep-state-only" option
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) ___ 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"
[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 2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03.02.2015 19:13, 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".
- --
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJU0P2bXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePkkoQAJHlybB+Hmcae64Bu5CyimWy
FJsicjr/DkNLhzAVJAglslBqgEkSrN2CiYTaASMMTmg6bj8RL6LLHWm0v/bAYQQR
lMGqCCcz+NvKjrB2D4egRYkA4NHGQ60Lj4O4YfsNOc9Jrsyn7RAqVc9vwMXT/GvN
GmDgVqsgA+IWSNZ4flE/MbnkZ8tq/jztuxaQneeKq6qmT9HaiNN8QeNrecO0kghz
GXZCXTGVgoguv4K/SDTkqcKapL7vP1mzRuR34FQcN/Mmj4lJ9Mdk2JNzIg0YHBZ+
HzvRvoNBHJfgw1G5ydORGOeIBgd5XCzlYTws2dboksLrd3taF4emDGjpvzn+Qwzd
X7B2hRnSOByM5j8LfctO2E7Zj7zPDtVtlZ3YsCpKvWzCdtSthzQAlvB/iE9CBOis
JAXbINONngevwwrWqCsZCxgXCGSrp9scGHY7Es02M2Pov6GSzXtPq1349SmFrH5I
J/ijTfV8e0kNnwBHfy/jf5wpXNQSV93IqRwDNp5jG+0qtDL2ZZNhMamELauWhbhB
nTJ+Og2TsPeOSp88/Jb6bW+pIsDQ7XIxdBNFC0j9lU/jFwNIfAK5xkvc239IsqeC
ylQGghwiGl9E4P3yIhLa2OAUdCy9J+dw8ZlyBkS3pN27j/RIoyMvkAA5l8i6dVRR
AEfyn36tKaR/BEUkGN5g
=9avV
-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 @@
/*
* generate O_PROBE_STATE if necessary
*/
- if (have_state && have_state->opcode != O_CHECK_STATE) {
+ if (have_state && have_state->opcode != O_CHECK_STATE &&
+ have_state->opcode != O_STATE_ONLY) {
fill_cmd(dst, O_PROBE_STATE, 0, 0
Re: [RFC][patch] New "keep-state-only" option (version 2)
On 2/4/15 12:55 AM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 19:13, 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". agreed.. I hate the implied check-state.. man page must be very explicit about this.. ___ 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 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 (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"
