-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
> packe
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.
-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 al
-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 t
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
> > >
-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 N
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
-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
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 t
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 o
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
-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
> |
-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:
>>
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 patte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03.02.2015 09:44, Julian Elischer wrote:
>> So, stateful firewall with NAT could be rewritten like this:
>>
>> add 1000 skipto 2000 all from any to any out xmit outIface add
>> 1010 skipto 3000 all from any to any in recv outIface
>>
>> add 20
*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 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 create new
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 "al
17 matches
Mail list logo
