-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
-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
-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
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.
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
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
-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
-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
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
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
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
-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)
-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
||
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
On 2/3/15 3:17 AM, Lev Serebryakov wrote:
I propose two new actions: state-allow and state-deny.
They imply keep-state and create new dynamic rules, when called
directly, but pass packet to NEXT rule after that (don't stop search).
When they are called as dynamic rule, they acts as
*cool, I like this, it got some points.*
*though the email is too long to be read.*
On 3 February 2015 at 14:44, Julian Elischer jul...@freebsd.org wrote:
On 2/3/15 3:17 AM, Lev Serebryakov wrote:
I propose two new actions: state-allow and state-deny.
They imply keep-state and
16 matches
Mail list logo
