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] Two new actions: state-allow and state-deny
On 2/3/15 6:23 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 13:04, Ian Smith wrote: Now to make stateful firewall with NAT you need to make some not very readable tricks to record state (allow) of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. google for FreeBSD ipfw nat stateful :) There are lot of them. Not real HOWTOs, but blog posts alike. BTW, without new mechanism it is really hard to do such firewall, as we need action (nat) after allow keep-state. It could be done with this ugly skip-to or with allow keep-state in INCOMING section of firewall, what is not much better, as I prefer to decide let packet out or not in OUTCOMING part of firewall and with allow keep-state in incoming path it flood state table with unused states. Another problem, that keep-state acts as check-state too, so you could not have ANOTHER keep-state before NAT in outgoing part or you miss nat completely (sate is created in outgoing path, and then checked before nat in outgoing path with keep-state, gr, ugly!). 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..) - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KGqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePYvYQALeGCF9EuZKP3jLDaRwad+TO IhYq5I3xPPqU3eNEdQ6OqdFonVQ4mDB+UipZzspC/U5drf1qo2LkOF8oBNDlVDW4 2I+bgYStptIkpSoBOe5AGRYwO3jfec77GvXhR8cMeQZK2Z9NIazn5ZtFkdQyiiDU +b7pxBQ0SbbMUT3hubl4H+v93dMGfjnzrFg1aSY4/uYnmilb8plWN1o4BshZVMSz z1lrFSaorj4RNYxnpM6f6YtDDYx4TahA7+OILl/BvzmNoztWb5hKNX+1TGLZPcch QE19iix+8O75yuVEMim6FxZ7u6sRk+4PpL/WzCLC2PpPxP/AyiFRh4zw7Q34HDNm xPe4Nfzt5vDj0/2HYMY0q0UeSfVY/U0iB3TWmV/3HFObaLeibCgHqOFGmtCpHw5/ EXJX36mpffO1wI6ImPAvQ9C/wE6/JdoL8R3EPrsN3hdNmoVNIrnDuaeAwiQM6Ljm 4CHzsqlYYzyjzgyMmmJahaZ3Lrr0IjnVixC3/z46SfpPipaua8Pr+oZozC4WFmnn 4IhsXH+XK7fTbKQaZML6o9j6Bm0hs9g6mt+VSWCYWGCHh/V3DzTuH2BECUeC8lsD 9pwHv4x4vPbh7d/kBwAl75mOe3etb8nD/+i+x0oqbPn0T73DgdGgYPnIKqElOi4Y Ws6uw/Euno3YnSSds5Eb =FJZe -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 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
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] Two new actions: state-allow and state-deny
On 2/3/15 5:30 PM, Lev Serebryakov wrote: 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. yes, because NAT is a stateful filter so it's a duplication - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) ___ 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
-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 },
{ layer2, TOK_LAYER2
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);
dst = next_cmd(dst, rblen);
}
Re: [RFC][patch] Two new actions: state-allow and state-deny
On Tue, 3 Feb 2015 13:23:38 +0300, Lev Serebryakov wrote: On 03.02.2015 13:04, Ian Smith wrote: Now to make stateful firewall with NAT you need to make some not very readable tricks to record state (allow) of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. google for FreeBSD ipfw nat stateful :) There are lot of them. Not real HOWTOs, but blog posts alike. As I suspected, most of them either are or refer to or are based on the handbook IPFW page, which I believe has caused more damage to the cause of IPFW adoption and usage than anything else. ipfw(8) is your friend, and pretty much your only friend in this regard. Of those, https://nileshgr.com/2014/12/07/freebsd-ipfw-nat-jails isn't bad. Many of the others are up to 10 years old and not much help. http://www.pl.freebsd.org/doc/handbook/firewalls-ipfw.html is an earlier version of https://www.freebsd.org/doc/handbook/firewalls-ipfw.html which has undergone significant improvement lately (compare), but still contains factual errors in the rulesets and very muddle-headed ideas regarding syslog and other things, IMHO. I'd best say no more on this topic; you can't discombobulate confusion. Cheers, Ian out BTW, without new mechanism it is really hard to do such firewall, as we need action (nat) after allow keep-state. It could be done with this ugly skip-to or with allow keep-state in INCOMING section of firewall, what is not much better, as I prefer to decide let packet out or not in OUTCOMING part of firewall and with allow keep-state in incoming path it flood state table with unused states. Another problem, that keep-state acts as check-state too, so you could not have ANOTHER keep-state before NAT in outgoing part or you miss nat completely (sate is created in outgoing path, and then checked before nat in outgoing path with keep-state, gr, ugly!). - -- // Lev Serebryakov AKA Black Lion ___ 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 03.02.2015 13:04, Ian Smith wrote: Now to make stateful firewall with NAT you need to make some not very readable tricks to record state (allow) of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. google for FreeBSD ipfw nat stateful :) There are lot of them. Not real HOWTOs, but blog posts alike. BTW, without new mechanism it is really hard to do such firewall, as we need action (nat) after allow keep-state. It could be done with this ugly skip-to or with allow keep-state in INCOMING section of firewall, what is not much better, as I prefer to decide let packet out or not in OUTCOMING part of firewall and with allow keep-state in incoming path it flood state table with unused states. Another problem, that keep-state acts as check-state too, so you could not have ANOTHER keep-state before NAT in outgoing part or you miss nat completely (sate is created in outgoing path, and then checked before nat in outgoing path with keep-state, gr, ugly!). - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KGqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePYvYQALeGCF9EuZKP3jLDaRwad+TO IhYq5I3xPPqU3eNEdQ6OqdFonVQ4mDB+UipZzspC/U5drf1qo2LkOF8oBNDlVDW4 2I+bgYStptIkpSoBOe5AGRYwO3jfec77GvXhR8cMeQZK2Z9NIazn5ZtFkdQyiiDU +b7pxBQ0SbbMUT3hubl4H+v93dMGfjnzrFg1aSY4/uYnmilb8plWN1o4BshZVMSz z1lrFSaorj4RNYxnpM6f6YtDDYx4TahA7+OILl/BvzmNoztWb5hKNX+1TGLZPcch QE19iix+8O75yuVEMim6FxZ7u6sRk+4PpL/WzCLC2PpPxP/AyiFRh4zw7Q34HDNm xPe4Nfzt5vDj0/2HYMY0q0UeSfVY/U0iB3TWmV/3HFObaLeibCgHqOFGmtCpHw5/ EXJX36mpffO1wI6ImPAvQ9C/wE6/JdoL8R3EPrsN3hdNmoVNIrnDuaeAwiQM6Ljm 4CHzsqlYYzyjzgyMmmJahaZ3Lrr0IjnVixC3/z46SfpPipaua8Pr+oZozC4WFmnn 4IhsXH+XK7fTbKQaZML6o9j6Bm0hs9g6mt+VSWCYWGCHh/V3DzTuH2BECUeC8lsD 9pwHv4x4vPbh7d/kBwAl75mOe3etb8nD/+i+x0oqbPn0T73DgdGgYPnIKqElOi4Y Ws6uw/Euno3YnSSds5Eb =FJZe -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 03.02.2015 12:30, Lev Serebryakov wrote: 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. Oh, I'm stupid! I know how to do keep-state-only cheap for fast path! I'll prepare new patch today or tomorrow. Also, I BADLY want keep-state-but-dont-check one. Sometimes it adds couple of skipto rules to avoid keep-state because it will trigger check too, even if MATCH will fail. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KJTXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTEMP/R3MZ8AmqKA0h7pFPy5SCwjT /zhnjjRvk+sDpc5BJPA/xIXV8IBupCPBCDR8CvCcqbaxFBECTTbW+JHCaHB0idXf F7lI2fTjiXcx5EK3E1RkjJ8dbRuHLAiYttMA4e1YIZBidsflgX/wLIEexseeia1K Vqh0NLofJLgzZET+wDbDBNncgWSaUnyJyW05BtVDUi/kpHekpZg4zm71gfWAoLgl tROv3i0y1YfkulwzZ84BcegsEAPMqD11AhSYZayeF1Ozl5jBGXTpC4rhaOQNYl7n +Hcr828rOZFiP/b4p/QhHx0TAMdYm3oqxSXMtr8GzWK+q5cClk7vdBv2Nj2W5f43 jOaJhDHgy21HxKCmFKKvSg/ZMb43F21ZHh0hU4eVlAK+AH74cli8hISTzZo4KxwC g74vUIPQkKs177UB+Hx1ADxwmur9fzbJpWWcK5zd/bLKQ8klUfiVrXp4awqLHma5 z6mKH89pxG9IC8rHFODetgfyvCJCiI0VY8bYuR8zJ6ciyk4NLGVhLk/VlzPyap8Y IT8O+kYLCaOWPbJvR+Zqti+hnvsk+5JnGxa16tVUkxXiJfh7VfWt9dDQ12Z9At1t srjr79R9yEJ0aPYKZRT4Z3q+CPhJZ+TpZyCxX3QT0vJuzewrj+R0CwSPP2xaWUZ3 x+Z6nsvc0bx37IgR7vsx =DlMK -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
reass all from any to any kills IPv6 packets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Recommended reass all from any to any in kills all incoming IPv6 packets (at least, packets from 6in4 tunnel). reass ip4 from any to any in works as expected. Is it documentation bug or implementation bug? - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KYjXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePAtwP+wX5m8V2lqQfpoHAeCcje4M/ 4pB4io/aNxvHQXevLqJl1kRCry9yvteUwJhnPKuBIov9OsNsGh2xe8t+JJh1JtIS 7qusKQpt17+QfW+t28m1p6p2bNLDa40NLDffaUOI5ClqXsiZf+vVhSs5Oyf9a2QB PcQ+y+kOgl/LodSfl1D5xI5mlVrJ5Pjz61+ShzPWyNB6aXjrz+FN13b5+YQll0AV GN4nKDw+aqSOQtFxcomaF2qch0Wn5zJ9Q+fyMjslW6Ze8/oVYV4gmzhl0XOYY//h 6GLk2kavrxCO8IaWANEqYbF9t64C95WSkWVeTqICPHoxs5Wvy6wlnyw4f0qRevR9 UzCn5Z/Oe2GbAvjr0p/6h+PlXnT99Rhnl0k14WMpjlPtH3hasi0tdHrJfm63dTu7 hutZol1nfzOXwrooBA9QCE8QV0flRau4GR/Qf/2PDQmtv3zcF1y6ThanTYX2sGRl hBdcvohzicG/P0W9jAPkiCI1fd23bi2goLo/Q7GtScKBjegpRNSH1sWbNyRHFUm7 5X9KIONK+2aZbIFseyyfGD4+pb5vMZQwqgXXAH5NkBNbyRwll3QnaaNv8Rqx6zNy 9Mkyn2RInWjr+bYqPHH8kB50SunPI5Hjx/7vc/ScMV0BbllqiUriYbOsSKadIUqf B4JONNRMRU0ZEwBWi71J =j4f0 -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 Mon, 2 Feb 2015 22:17:25 +0300, Lev Serebryakov wrote: Now to make stateful firewall with NAT you need to make some not very readable tricks to record state (allow) of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. 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
