Stateless Feature of Security Group Not Functioning in Case of other Port same compute use statefull

Bug #2020060 reported by Phat
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
New
Undecided
Slawek Kaplonski

Bug Description

From my lab, I tried to apply the stateless securigty group for one port "172.26.9.54" and use hping3 to generate tcp connections and monitor the nf_conntrack number but nothing is effect. After debug in iptables rules, I saw the following syntax error in iptables caused the "no-track" policy to become ineffective:

This output from `iptables-save`:
## The port of the first server use same subnet (Public Subnet of provider) - IP address 172.26.9.97
Line 33: -A neutron-linuxbri-PREROUTING -m physdev --physdev-in brq959cb64a-b4 -m comment --comment "Set zone for 76a0ad0-20" -j CT --zone 4099
Line 34: -A neutron-linuxbri-PREROUTING -i brq959cb64a-b4 -m comment --comment "Set zone for 76a0ad0-20" -j CT --zone 4099
Line 35: -A neutron-linuxbri-PREROUTING -m physdev --physdev-in tap076a0ad0-20 -m comment --comment "Set zone for 76a0ad0-20" -j CT --zone 4099

## The port of the second server use same subnet (Public Subnet of provider) - IP Address 172.26.9.54
Line 52: -A neutron-linuxbri-PREROUTING -m physdev --physdev-in brq959cb64a-b4 -m comment --comment "Make ec8b333-40 stateless" -j CT --notrack
Line 53: -A neutron-linuxbri-PREROUTING -i brq959cb64a-b4 -m comment --comment "Make ec8b333-40 stateless" -j CT --notrack
Line 54: -A neutron-linuxbri-PREROUTING -m physdev --physdev-in tapdec8b333-40 -m comment --comment "Make ec8b333-40 stateless" -j CT --notrack

Phat (letonphat1988)
tags: added: firewall group security
Revision history for this message
Rodolfo Alonso (rodolfo-alonso-hernandez) wrote :

Hello Path:

I guess you are using ML2 Linux Bridge (with the iptables firewall). Please, provide the version of OpenStack used. If possible, provide a full dump of iptables, the ports used and the SG and rules description. The iptables version could be useful too.

If I'm not wrong, the problem here is that Line 34 and Line 53 are clashing. The first one is tracking the interface traffic in zone 4099 and the second one is marking this traffic a "no tracking". I guess this is a corner case not covered during the development nor the testing.

Let me remark that ML2/LB is in experimental support mode. That means it is no longer actively supported by the Neutron community. You could study moving to other mechanism drivers like ML2/OVS or ML2/OVN.

Regards.

Revision history for this message
Phat (letonphat1988) wrote :

Hello Rodolfo,
Your answer so helpful. This is my env:
    - Openstack Victory
    - Neutron: ML2 Linux Bridge
    - Deployer: Openstack Kolla
I uploaded my iptables-save to this post but just remind this dump isn't same the last one but the bug behavior is the same. BTW, I known linuxbridge is in experimental support mode but I see the code ML2 use for Linuxbridge and the OVS is shared codes sothat I hope I posted a helpful topic for both. Do you have any workaround for this case ?

tags: added: linuxbridge
Changed in neutron:
assignee: nobody → Slawek Kaplonski (slaweq)
Revision history for this message
Ihar Hrachyshka (ihar-hrachyshka) wrote :

This doesn't address your problem with ML2/LB, but FYI ML2/OVN stateless SG implementation addresses the problem by making sure that filters don't clash and that stateless ACLs are given priority.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.