security group function not work on active traffic session

[Xiao Li Xu]

Setup info: Liberty with networking-ovn.

Steps :
[1] Create tenant.
[2] Create network, boot 8 instances on that network ,
[3] Configure Security group rules to allow all ICMP, all TCP and all UDP traffic
[4] Associate FIP
Ping to FIP from your laptop , make sure ping is going through
[5] Now modify security group rule - remove all ICMP rule from the security group
Ideally ping should time out, but I could able to ping to the FIP
Tried to ping other instances which doesn't have active ping running, ping was timing out for all the other FIPs

[Russell Bryant (russellb)]

Indeed, we currently do nothing to conntrack state when security groups get changed. Existing connections that were allowed when they were established will remain.

[Ramu Ramamurthy (ramu-ramamurthy)]

sort of similar to this one (non-ovn) wherein conntrack entries needed to be forced out from user-space using conntrack-tools

https://bugs.launchpad.net/neutron/+bug/1335375

[Ramu Ramamurthy (ramu-ramamurthy)]

THe problem reproduces as below..

Initially a ping session was started with a VM from the dhcp namespace.
The relevant OVN acl shows as:
from-lport 1002 (inport == "da8bd41a-5809-4036-8a12-af6d4140685c" && ip4) allow-related
to-lport 1002 (outport == "da8bd41a-5809-4036-8a12-af6d4140685c" && ip4 && icmp4) allow-related

Conntrack on that connection shows:
[stack@ovncontroller-01 devstack]$ sudo conntrack -L | grep 10.0.0.4
icmp 1 29 src=10.0.0.2 dst=10.0.0.4 type=8 code=0 id=27789 src=10.0.0.4 dst=10.0.0.2 type=0 code=0 id=27789 mark=0 zone=3 use=1
icmp 1 29 src=10.0.0.2 dst=10.0.0.4 type=8 code=0 id=27789 src=10.0.0.4 dst=10.0.0.2 type=0 code=0 id=27789 mark=0 zone=1 use=1

Now the ICMP security group rule is deleted
[stack@ovncontroller-01 devstack]$ neutron security-group-rule-delete e3a3888b-e0c8-4af9-88a0-17f1c617a4ff

Conntrack still shows the connection and ping is still ongoing to the VM
[stack@ovncontroller-01 devstack]$ sudo conntrack -L | grep 10.0.0.4
icmp 1 29 src=10.0.0.2 dst=10.0.0.4 type=8 code=0 id=27789 src=10.0.0.4 dst=10.0.0.2 type=0 code=0 id=27789 mark=0 zone=3 use=1
icmp 1 29 src=10.0.0.2 dst=10.0.0.4 type=8 code=0 id=27789 src=10.0.0.4 dst=10.0.0.2 type=0 code=0 id=27789 mark=0 zone=1 use=1

Now we delete the conntrack state as below:
[stack@ovncontroller-01 devstack]$ sudo conntrack -D -p icmp -s 10.0.0.2 -d 10.0.0.4
icmp 1 29 src=10.0.0.2 dst=10.0.0.4 type=8 code=0 id=27789 src=10.0.0.4 dst=10.0.0.2 type=0 code=0 id=27789 mark=0 zone=3 use=1
icmp 1 29 src=10.0.0.2 dst=10.0.0.4 type=8 code=0 id=27789 src=10.0.0.4 dst=10.0.0.2 type=0 code=0 id=27789 mark=0 zone=1 use=1
conntrack v1.4.2 (conntrack-tools): 2 flow entries have been deleted.

Then the ping to the VM stops.

[Russell Bryant (russellb)]

Ramu, you mentioned that you're working on this. What approach are you taking? I had some ideas but wanted to check on what you're doing to see if it was the same approach or not ...

[Ramu Ramamurthy (ramu-ramamurthy)]

Russell, It will take me some time (I would think a week) to propose an approach, as I need to first understand the code in the ovn-controller. But I see this bug (and the other related one on conntrack) as a good opportunity to bootstrap. If you have a fix in the works, please take it as I can start on another bug.

[Russell Bryant (russellb)]

I don't have a fix. If I come up with a proposal, I'll update this bug.

[Russell Bryant (russellb)]

I started a thread on the ovs dev mailing list to discuss this issue: http://openvswitch.org/pipermail/dev/2016-February/065429.html

[Russell Bryant (russellb)]

I have a patch for this that is working in my simple testing. If anyone else is interested in helping test it, it's in this branch:

https://github.com/russellb/ovs/commits/acls

I still need to update the patch with a real commit message and documentation updates, but I think the code is pretty much ready.

[Russell Bryant (russellb)]

I posted a patch series for this on the ovs-dev list: http://openvswitch.org/pipermail/dev/2016-March/067093.html

[Kyle Mestery (mestery)]

Patches still under review in OVS:

https://patchwork.ozlabs.org/patch/637301/

[Russell Bryant (russellb)]

This should now resolved as of this commit:

https://github.com/openvswitch/ovs/commit/cc58e1f2cc414b844c36d21a9a39e4f3383e75e4