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
