Attached port with disabled security does not work properly

[Bartłomiej Daca]

When I attach port with disabled security to a vm, I am not able to use this port.

Steps to reproduce:

1. Create port and disable security:

neutron port-create --name test-sec-group --no-security-groups <net_id>
neutron port-update <port_id> --port-security-enabled=False

2. Attach port to vm

nova interface-attach <server_id> --port-id <port_id>

After this steps I am unable to use this port on the vm (for example obtain dhcp lease). The cause that I identified is that after this steps the iptables on the host with vm is not configured properly. I can't see rules that should be there:

-A neutron-openvswi-FORWARD -m physdev --physdev-out <port_interface> --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT
-A neutron-openvswi-FORWARD -m physdev --physdev-in <port_interface> --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT
-A neutron-openvswi-INPUT -m physdev --physdev-in <port_interface> --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT

When I add this rules manually, everything works fine.

Another scenario when everything works fine: change steps order - create port, attach it and then disable security.

My environment:
* Openstack mitaka on centos 7
* neutron version: neutron-8.2.0
* nova version: nova-13.1.1

[Kevin Benton (kevinbenton)]

I just did some testing locally and looked at the code. When a port is created with port security disabled, the OVS agent will not inform the firewall driver at all about the port so no iptables rules will be created. So those rules missing should not prevent traffic from flowing since there shouldn't be any iptables rules on the filtering bridge. I tested this on my development VM and the workflow works fine.

Can you please run an 'iptables-save | grep <first 5 chars of port UUID>' so we can see if there are somehow some other rules interfering with traffic?

[Kevin Benton (kevinbenton)]

You can also try running tcpdump on the filtering bridge to see traffic flowing by. The bridge is 'qbr' followed by the start of the UUID of the port.

[Bartłomiej Daca (bartek-daca)]

Hello Kevin, thank you for taking a look on this bug.

iptables is empty for this port, greping iptables-save gave empty result.

Absence of these rules mentioned in the bug description means that the traffic rules will "fallback" to the default policies on the physical node. I have checked it - by default I have all policies set to DROP on the node. When I change them to ACCEPT:

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

everything works good. I can use the port on the vm, obtain dhcp lease and everything - it is fully functional. Nevertheless, I would rather have DROP policies set. Is it possible to configure neutron to add these "ACCEPT" rules always?

As an additional information: network in which I create the port is a VLAN, I don't know if this is important in this case.

[Kevin Benton (kevinbenton)]

No, unfortunately it's not configurable. We could potentially change the behavior to always generate allow rules. However, it would be a behavior change in the semantics between the L2 agent and the firewall driver so we probably wouldn't be able to back-port it.

[Bartłomiej Daca (bartek-daca)]

I don't count on it, mitaka is not the most actual after all. Is it possible to be implemented in ocata cycle?

[Kevin Benton (kevinbenton)]

Yes, we should be able to get this fix in Ocata. See the bug this duplicates.