modified FORWARD policy name to ACCEPT and enabled by default ESTABLISHED

[smagnani96]

FIX #331
ENHANCE #334

Tried quickly with docker s41m0n/polycube:fulvio, if someone can help testing this and modifying all the tests accordingly would be amazing.

Signed-off-by: Simone Magnani simonemagnani.96@gmail.com

[goldenrye]

Actually we can first configure the rule allowing the ssh traffic before attaching the firewall to the interface.

…

On Tue, Sep 22, 2020 at 7:38 AM Fulvio Risso ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/services/pcn-firewall/datamodel/firewall.yang <#337 (comment)> : > @@ -92,8 +92,8 @@ module firewall { leaf action { type action; polycube-base:init-only-config; - description "Action if the rule matches. Default is DROP."; - polycube-base:cli-example "DROP, FORWARD, LOG"; + description "Action if the rule matches. Default is ACCEPT."; This was changed recently because of a logistical problem. Let's assume you deploy a firewall on a remote machine, and the default action is DROP. What happens, is that as soon as you start the firewall, you loose the connection to the remote machine. So, to avoid this problem (very important in real deployments), we changed the default action to ACCEPT. Obviously, the user can change it to DROP upon its preferences, hopefully after having properly configured the ruleset. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#337 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD5DPPH64HABKHAC7CZT43DSHCZEZANCNFSM4RVDUYTQ> .

[goldenrye]

Accept the 'accept' as default to minimize the impact to deployment

[frisso]

/rebase

[polycube-bot]

Rebase status: success!

[acloudiator]

/rebase

[polycube-bot]

Rebase status: success!

[smagnani96]

++++TEST ./../src/services/pcn-firewall/test/ping/test_ping_5.1.sh Failed++++
cause: unknown

++++TEST ./../src/services/pcn-firewall/test/tcp/test_tcp_4.sh Failed++++
cause: netcat connection time out

@FedeParola Can you help checking these two tests please? This is taking more time than expected

[FedeParola]

I may have found the cause of the problem @s41m0n.
Jenkins slaves use a old version of the kernel (4.15) that doesn't have support for bounded loops and has the limit of 4096 instructions per ebpf program. To overcome the first problem the firewall performs loop unrolling and apparently the number of rules of the test are causing the size of the program to exceed the limit (at least this is what happens when I downgrade the kernel on my machine). Could you try lowering that number? In my tests 2000 rules seem to be safe.

I still don't understand why the same tests passed formerly... But it is worth giving a try

[FedeParola]

Maybe I found out why the tests are passing on the master: original tests use a batch file to carry rules and then pass this file to the polycubectl command, however probably this method doesn't work and no instruction is added at all, leaving only the default (forward) policy.

[smagnani96]

I may have found the cause of the problem @s41m0n.
Jenkins slaves use a old version of the kernel (4.15) that doesn't have support for bounded loops and has the limit of 4096 instructions per ebpf program. To overcome the first problem the firewall performs loop unrolling and apparently the number of rules of the test are causing the size of the program to exceed the limit (at least this is what happens when I downgrade the kernel on my machine). Could you try lowering that number? In my tests 2000 rules seem to be safe.

I still don't understand why the same tests passed formerly... But it is worth giving a try

The number of rules injected is the same, it hasn't changed.
Even when there was the "transactional" mode instead of batch rule injection we used to insert more than 4000 rules

[smagnani96]

Maybe I found out why the tests are passing on the master: original tests use a batch file to carry rules and then pass this file to the polycubectl command, however probably this method doesn't work and no instruction is added at all, leaving only the default (forward) policy.

I remember to have tested file injection with "polycubectl" with Fulvio and it seemed to work. Anyway, now the rules are correctly inserted, I am able to see them all, and locally the test passes :(

[FedeParola]

Maybe I found out why the tests are passing on the master: original tests use a batch file to carry rules and then pass this file to the polycubectl command, however probably this method doesn't work and no instruction is added at all, leaving only the default (forward) policy.

I remember to have tested file injection with "polycubectl" with Fulvio and it seemed to work. Anyway, now the rules are correctly inserted, I am able to see them all, and locally the test passes :(

Yes you are right, I didn't check too accurately, sorry.

I may have found the cause of the problem @s41m0n.
Jenkins slaves use a old version of the kernel (4.15) that doesn't have support for bounded loops and has the limit of 4096 instructions per ebpf program. To overcome the first problem the firewall performs loop unrolling and apparently the number of rules of the test are causing the size of the program to exceed the limit (at least this is what happens when I downgrade the kernel on my machine). Could you try lowering that number? In my tests 2000 rules seem to be safe.
I still don't understand why the same tests passed formerly... But it is worth giving a try

The number of rules injected is the same, it hasn't changed.
Even when there was the "transactional" mode instead of batch rule injection we used to insert more than 4000 rules

Ok then the overflow is probably caused by the DEBUG instructions, try instantiating the firewall with no loglevel (default=INFO) and the problem should be gone.

[smagnani96]

@FedeParola thanks, the debug option seemed to alter some test, it worked.