FWaaS let connection opened if delete allow rule, beacuse of conntrack

[Peter]

Hi,

I've faced a problem with FWaaS plugin in Neutron (Juno).
The firewall works, but when I delete a rule from the policy, the
connection will still works because of conntrack... (I tried with ping,
and ssh)
It's okay, if the connection will kept alive, if it's really alive, (an
active SSH for example) but if I delete the ICMP rule, and stop pinging,
and restart pinging, the ping will still works...

If I go to my neutron server, and do a conntrack -F command on my
relevant qrouter, the firewall starts working based on the valid rules...

Are there any way, to configure the conntrack cleanup when FWaaS
configuration modified by user?

If not, can somebody help me, where to make changes on code, to run that
command in the proper namespace after the iptables rule-generation?

Regards,
 Peter

[Elena Ezhova (eezhova)]

I tried to reproduce this on stable/juno but I didn't get a problem that is described in bug report. When I deleted a rule from a policy all new connections got rejected. If this bug is still valid, could you please provide more details on how to reproduce this?

[Peter (fazy)]

Hi,

We tried a few times this bug, and I think, the windows based ping do that (from linux, we cannot reproduce either).

Anyways, as you wrote before, the new connections got rejected, but what if someone attacking you, and you want to block that traffic? While he has an ESTABLISHED connection to your router, the connection will be active, and a deny rule on FWaaS don't help on that...

I think, FWaaS need to apply the rules, what you add, and not allow the traffic based on what remain in the conntrack table, so the cleaning on change (maybe just on rule delete, deny rule add, and allow->deny rule change event) would be nice (as an configurable option for example)

Regards,
 Peter

[Elena Ezhova (eezhova)]

As for ESTABLISHED connctions that remain active after a corresponding rule is deleted - this is a known issue and there is some work in progress to fix this for security groups (see bug [1] and proposed fix [2]). The same approach could be used for FWaaS, I guess.

As the bug itself , as you say, is a Windows issue I remove my assignment so that someone with necessary resources can pick it up and verify.

[1] https://bugs.launchpad.net/neutron/+bug/1335375
[2] https://review.openstack.org/#/c/147713/

[Sean M. Collins (scollins)]

Changing this to new, in order to keep it from expiring, until we evaluate

[Miguel Angel Ajo (mangelajo)]

This was something that was addressed in security groups by setting every port to a different security group zone in which entries are removed when rules are removed.

Is that supported in Fwass?

[Miguel Angel Ajo (mangelajo)]

security group zone -> conntrack zone (in my last email). Btw, that solution is giving us a bit of headache as you can see here: https://bugs.launchpad.net/bugs/1513765 so please consider the scalability of the conntrack tool & kernel in that regard.

[watanabe.isao (watanabe.isao)]

We are facing the same questions:
- FW rule need to be refreshed, as soon as the new deny rule has been added, or allow rule has been deleted, to prevent some security issues.
- The new solution need to fit the scalability of the conntrack tool & kernel.

Hello, @dnovosel (dnovosel)
Are you still working on this issue, please?
I would like to do everything I can do, to improve this issue in Mitaka or early N.
Could you please, let me know your plan and progress?
I also would like to share our current idea about this issue.
If it is OK, shall we discuss about this in ML or private mail, please?

Hello, @Miguel Angel Ajo (mangelajo)
Sir, if we need to start another rfe tagged bug report, and update the discussion result there, please tell me.

[Ha Van Tu (tuhv)]

As I investigated, the bug is still making the connection problems in both Linux and Windows based pings.
When we apply a blocked rule to a current connection, the firewall should block this connection. However, the current firewall doesn't.
Is it OK if I assign myself to fix this bug?
Thanks,

[watanabe.isao (watanabe.isao)]

Hello, all
@Ha Van Tu (tuhv) is a co-worker of mine.

[Ha Van Tu (tuhv)]

Hi all,
I have already do some experiments to check the problems, and I would like to share the results:

A. Topology:

(Outside computers)| ------>[Network node (router - with firewall)] --------> [Compute Node (VM1 with floating IP)]
(Outside computers)| <------[Network node (router - with firewall)] <-------- [Compute Node (VM1 with floating IP)]
VM1 is associated with a floating IP
Perform pinging from outside computers(Both user Linux and Windows computer) to the VM1

B. Test cases:
        1. From no firewall, pinging, apply a firewall with no rule, expect close pinging, but actually not
 2. From firewall with an allow rule, pinging, change the rule to drop/reject, expect close pinging, but actually not
 3. From firewall with an allow rule, pinging, remove the rule, expect close pinging, but actually not
 4. From firewall with an allow rule, pinging, insert a drop/reject rule, expect close pinging, but actually not

C. Further experiments:
        1. From no firewall, pinging, apply a firewall with no rule, remove conntrack entries[1], expect close pinging, close pinging
 2. From firewall with an allow rule, pinging, change the rule to drop/reject, remove conntrack entries[1], expect close pinging, close pinging
 3. From firewall with an allow rule, pinging, remove the rule, remove conntrack entries[1], expect close pinging, close pinging
 4. From firewall with an allow rule, pinging, insert a drop/reject rule, remove conntrack entries[1], expect close pinging, close pinging

[1]: Follow steps in Network node:
 + Finding router namespace: sudo ip netns
 + Remove conntrack entries: sudo ip netns exec [routernamespace] conntrack -F

So, I can raise my conclusion:
        1. The problem that @Peter report is a bug ( In all cases in my testcases, it should close the existing connection)
        2. We can figure out this bug by deleting the conntrack entries (conntrack -F is just a simple testing solution)

Could I upload my solution into the Gerrit, you can look at it and leave further comments?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/300960

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/300960
Committed: https://git.openstack.org/cgit/openstack/neutron-fwaas/commit/?id=fadfe86516de7982c86de4dd1a0d275d0a6c84f7
Submitter: Jenkins
Branch: master

commit fadfe86516de7982c86de4dd1a0d275d0a6c84f7
Author: Ha Van Tu <email address hidden>
Date: Mon Apr 4 14:03:12 2016 +0700

    Fix "Not applying Firewall rules immediately" problem

    This patch removes the conntrack entries of the established
    connection when the firewall updates its rules.

    Change-Id: I8d149d3cb0c8cbca2211446b082fcfcda93e2b19
    Closes-Bug: #1474279

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron-fwaas 9.0.0.0b1 development milestone.

[Soumya Kolbhandari (soumya-kolbhandari)]

Anything regarding backporting it to stable/mitaka.

[Soumya Kolbhandari (soumya-kolbhandari)]

This issue can be seen on stable/mitaka also and the fix resolves it there too.
Is there any plan to backport it to stable/mitaka @Ha Van Tu ?