Port Security does not consistently update nova iptables

[Tyler Bishop]

I have created a network with port security set to enabled. I have set --no-security-group and --port_security_enabled=False on the port however the iptables on the hypervisor is not consistently set.

I have 2 VM on this hypervisors:

VM1:
tap0cc26c65-d1

VM2:
tap672dbe42-10

Dump of iptables save:
-A INPUT -j neutron-openvswi-INPUT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j neutron-filter-top
-A FORWARD -j neutron-openvswi-FORWARD
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -j neutron-filter-top
-A OUTPUT -j neutron-openvswi-OUTPUT
-A OUTPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT
-A neutron-filter-top -j neutron-openvswi-local
-A neutron-openvswi-FORWARD -m physdev --physdev-out tap85e24fb1-61 --physdev-is-bridged -m comment --comment "Direct traffic from the VM interface to the security group chain." -j neutron-openvswi-sg-chain
-A neutron-openvswi-FORWARD -m physdev --physdev-in tap85e24fb1-61 --physdev-is-bridged -m comment --comment "Direct traffic from the VM interface to the security group chain." -j neutron-openvswi-sg-chain
-A neutron-openvswi-FORWARD -m physdev --physdev-out tap1fe43774-ef --physdev-is-bridged -m comment --comment "Direct traffic from the VM interface to the security group chain." -j neutron-openvswi-sg-chain
-A neutron-openvswi-FORWARD -m physdev --physdev-in tap1fe43774-ef --physdev-is-bridged -m comment --comment "Direct traffic from the VM interface to the security group chain." -j neutron-openvswi-sg-chain
-A neutron-openvswi-FORWARD -m physdev --physdev-out tap0cc26c65-d1 --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT
-A neutron-openvswi-FORWARD -m physdev --physdev-in tap0cc26c65-d1 --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT
-A neutron-openvswi-INPUT -m physdev --physdev-in tap85e24fb1-61 --physdev-is-bridged -m comment --comment "Direct incoming traffic from VM to the security group chain." -j neutron-openvswi-o85e24fb1-6
-A neutron-openvswi-INPUT -m physdev --physdev-in tap1fe43774-ef --physdev-is-bridged -m comment --comment "Direct incoming traffic from VM to the security group chain." -j neutron-openvswi-o1fe43774-e
-A neutron-openvswi-INPUT -m physdev --physdev-in tap0cc26c65-d1 --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT
-A neutron-openvswi-i1fe43774-e -m state --state RELATED,ESTABLISHED -m comment --comment "Direct packets associated with a known session to the RETURN chain." -j RETURN
-A neutron-openvswi-i1fe43774-e -s 10.1.51.1/32 -p udp -m udp --sport 67 -m udp --dport 68 -j RETURN
-A neutron-openvswi-i1fe43774-e -p tcp -m tcp -m multiport --dports 1:65535 -j RETURN
-A neutron-openvswi-i1fe43774-e -p udp -m udp -m multiport --dports 1:65535 -j RETURN
-A neutron-openvswi-i1fe43774-e -m set --match-set NIPv4a5bf8991-231c-43db-9dd0- src -j RETURN
-A neutron-openvswi-i1fe43774-e -p icmp -j RETURN
-A neutron-openvswi-i1fe43774-e -m state --state INVALID -m comment --comment "Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack." -j DROP
-A neutron-openvswi-i1fe43774-e -m comment --comment "Send unmatched traffic to the fallback chain." -j neutron-openvswi-sg-fallback
-A neutron-openvswi-i85e24fb1-6 -m state --state RELATED,ESTABLISHED -m comment --comment "Direct packets associated with a known session to the RETURN chain." -j RETURN
-A neutron-openvswi-i85e24fb1-6 -s 10.1.51.1/32 -p udp -m udp --sport 67 -m udp --dport 68 -j RETURN
-A neutron-openvswi-i85e24fb1-6 -p tcp -m tcp -m multiport --dports 1:65535 -j RETURN
-A neutron-openvswi-i85e24fb1-6 -p udp -m udp -m multiport --dports 1:65535 -j RETURN
-A neutron-openvswi-i85e24fb1-6 -m set --match-set NIPv4a5bf8991-231c-43db-9dd0- src -j RETURN
-A neutron-openvswi-i85e24fb1-6 -p icmp -j RETURN
-A neutron-openvswi-i85e24fb1-6 -m state --state INVALID -m comment --comment "Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack." -j DROP
-A neutron-openvswi-i85e24fb1-6 -m comment --comment "Send unmatched traffic to the fallback chain." -j neutron-openvswi-sg-fallback
-A neutron-openvswi-o1fe43774-e -p udp -m udp --sport 68 -m udp --dport 67 -m comment --comment "Allow DHCP client traffic." -j RETURN
-A neutron-openvswi-o1fe43774-e -j neutron-openvswi-s1fe43774-e
-A neutron-openvswi-o1fe43774-e -p udp -m udp --sport 67 -m udp --dport 68 -m comment --comment "Prevent DHCP Spoofing by VM." -j DROP
-A neutron-openvswi-o1fe43774-e -m state --state RELATED,ESTABLISHED -m comment --comment "Direct packets associated with a known session to the RETURN chain." -j RETURN
-A neutron-openvswi-o1fe43774-e -j RETURN
-A neutron-openvswi-o1fe43774-e -m state --state INVALID -m comment --comment "Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack." -j DROP
-A neutron-openvswi-o1fe43774-e -m comment --comment "Send unmatched traffic to the fallback chain." -j neutron-openvswi-sg-fallback
-A neutron-openvswi-o85e24fb1-6 -p udp -m udp --sport 68 -m udp --dport 67 -m comment --comment "Allow DHCP client traffic." -j RETURN
-A neutron-openvswi-o85e24fb1-6 -j neutron-openvswi-s85e24fb1-6
-A neutron-openvswi-o85e24fb1-6 -p udp -m udp --sport 67 -m udp --dport 68 -m comment --comment "Prevent DHCP Spoofing by VM." -j DROP
-A neutron-openvswi-o85e24fb1-6 -m state --state RELATED,ESTABLISHED -m comment --comment "Direct packets associated with a known session to the RETURN chain." -j RETURN
-A neutron-openvswi-o85e24fb1-6 -j RETURN
-A neutron-openvswi-o85e24fb1-6 -m state --state INVALID -m comment --comment "Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack." -j DROP
-A neutron-openvswi-o85e24fb1-6 -m comment --comment "Send unmatched traffic to the fallback chain." -j neutron-openvswi-sg-fallback
-A neutron-openvswi-s1fe43774-e -s 10.1.50.200/32 -m mac --mac-source FA:16:3E:05:6F:A4 -m comment --comment "Allow traffic from defined IP/MAC pairs." -j RETURN
-A neutron-openvswi-s1fe43774-e -m comment --comment "Drop traffic without an IP/MAC allow rule." -j DROP
-A neutron-openvswi-s85e24fb1-6 -s 10.1.50.201/32 -m mac --mac-source FA:16:3E:73:89:67 -m comment --comment "Allow traffic from defined IP/MAC pairs." -j RETURN
-A neutron-openvswi-s85e24fb1-6 -m comment --comment "Drop traffic without an IP/MAC allow rule." -j DROP
-A neutron-openvswi-sg-chain -m physdev --physdev-out tap85e24fb1-61 --physdev-is-bridged -m comment --comment "Jump to the VM specific chain." -j neutron-openvswi-i85e24fb1-6
-A neutron-openvswi-sg-chain -m physdev --physdev-in tap85e24fb1-61 --physdev-is-bridged -m comment --comment "Jump to the VM specific chain." -j neutron-openvswi-o85e24fb1-6
-A neutron-openvswi-sg-chain -m physdev --physdev-out tap1fe43774-ef --physdev-is-bridged -m comment --comment "Jump to the VM specific chain." -j neutron-openvswi-i1fe43774-e
-A neutron-openvswi-sg-chain -m physdev --physdev-in tap1fe43774-ef --physdev-is-bridged -m comment --comment "Jump to the VM specific chain." -j neutron-openvswi-o1fe43774-e
-A neutron-openvswi-sg-chain -j ACCEPT
-A neutron-openvswi-sg-fallback -m comment --comment "Default drop rule for unmatched traffic." -j DROP
COMMIT

VM1 passes traffic just fine, VM2 does not because no rule is added.

I manually added these rules and traffic passes just fine:
iptables -A neutron-openvswi-INPUT -m physdev --physdev-in tap672dbe42-10 --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT
iptables -A neutron-openvswi-FORWARD -m physdev --physdev-out tap672dbe42-10 --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT
iptables -A neutron-openvswi-FORWARD -m physdev --physdev-in tap672dbe42-10 --physdev-is-bridged -m comment --comment "Accept all packets when port security is disabled." -j ACCEPT

Here are the port-show for each:
<email address hidden> > neutron port-show 672dbe42-10bb-4196-80ad-70a81488ad51
+-----------------------+--------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| binding:host_id | osc-1031.prd.cin1 |
| binding:profile | {} |
| binding:vif_details | {"port_filter": true, "ovs_hybrid_plug": true} |
| binding:vif_type | ovs |
| binding:vnic_type | normal |
| device_id | f4037cdd-e1ab-4e84-88e0-ef94f1b95b39 |
| device_owner | compute:None |
| dns_assignment | {"hostname": "host-8XXXXXX", "ip_address": "8.XXXXXX, "fqdn": "host-8-XXXXX.openstacklocal."} |
| dns_name | |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "b3409c40-d6e2-461a-8722-8e5e52624d52", "ip_address": "8.XXXXX"} |
| id | 672dbe42-10bb-4196-80ad-70a81488ad51 |
| mac_address | fa:16:3e:4a:18:df |
| name | |
| network_id | 0270175b-6c53-40ca-bb9e-22e2635cdaeb |
| port_security_enabled | False |
| security_groups | |
| status | ACTIVE |
| tenant_id | 42858ac565df4bf8aec64f871fe7e955 |
+-----------------------+--------------------------------------------------------------------------------------------------------------+
<email address hidden> > neutron port-show 0cc26c65-d1d7-45b1-a974-43fafc28a1ec
+-----------------------+--------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| binding:host_id | osc-1031.prd.cin1 |
| binding:profile | {} |
| binding:vif_details | {"port_filter": true, "ovs_hybrid_plug": true} |
| binding:vif_type | ovs |
| binding:vnic_type | normal |
| device_id | 1bf1e985-d317-4a7c-81c5-4dc32c889274 |
| device_owner | compute:zone1 |
| dns_assignment | {"hostname": "host-8-XXXXXXX2", "ip_address": "8.XXXXXX", "fqdn": "host-8XXXXXX.openstacklocal."} |
| dns_name | |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "b3409c40-d6e2-461a-8722-8e5e52624d52", "ip_address": "8.XXXXXXX"} |
| id | 0cc26c65-d1d7-45b1-a974-43fafc28a1ec |
| mac_address | fa:16:3e:4a:ab:45 |
| name | |
| network_id | 0270175b-6c53-40ca-bb9e-22e2635cdaeb |
| port_security_enabled | False |
| security_groups | |
| status | ACTIVE |
| tenant_id | 42858ac565df4bf8aec64f871fe7e955 |
+-----------------------+--------------------------------------------------------------------------------------------------------------+

[Tyler Bishop (tyler-bishop)]

Adding Yalei Wang as he wrote the IPtables engagement.

[yalei wang (yalei-wang)]

hi Tyler, which commands you used to create VM1 VM2? is there some other error log? and do you use the master branch?
I want to reproduced this problem.

[Tyler Bishop (tyler-bishop)]

Will update with exact commands and parameters. Thanks

[Tyler Bishop (tyler-bishop)]

 neutron port-create 4d2da18c-3563-485b-8781-bf5edded6ffb --fixed-ip subnet_id=a52d7bf4-d2fb-412e-948a-646736a81763,ip_address=10.1.50.201 --tenant-id=42858ac565df4bf8aec64f871fe7e955 --port_security_enabled=True

neutron port-create 0270175b-6c53-40ca-bb9e-22e2635cdaeb --fixed-ip subnet_id=b3409c40-d6e2-461a-8722-8e5e52624d52,ip_address=8.29.132.133 --tenant-id=42858ac565df4bf8aec64f871fe7e955 --port_security_enabled=False

 nova boot --flavor 2c7a07a5-f6d2-4ea6-903f-ffa22eb61301 --block-device-mapping vda=0387cdfd-6a2d-46cf-a9fc-94cbb8d473da:::0 --key-name tech --nic port-id=05b311e2-a3fc-4172-95b7-a36ae8bff94a --nic port-id=85e24fb1-6147-4f31-a282-f2c37b973b5c hafw01.prd.cin1

Using Neutron 7.0.1-1 from CentOS RDO Liberty

There are no errors in the logs, debug lacks any useful information about the iptables part. The bridge and openvswitch configure correctly but the iptables never get the allowed blocks added.

[Tyler Bishop (tyler-bishop)]

Does anyone know what lib the issue here is from?

[Sreenivas (sreenivas-pothukanoori)]

Tyler Bishop, could you please answer to the below queries to reproduce the bug,

> Does the VMs communication is in the same hypervisor(Controller) or across the hypervisors(Controller & Compute node).
> Does the traffic tested in this scenario is ping?
> "VM1 passes traffic just fine, VM2 does not because no rule is added.", Does it means VM1 is able to receive and send the traffic successfully to VM2 and VM2 does not send to the outgoing interface or VM2 itself is not receiving traffic from VM1 interface which is connected to VM2.

[Tyler Bishop (tyler-bishop)]

Hi Sreenivas,

1. No, traffic will not leave the VM.
2. All protocols.
3. VM1 had the correct rules in iptables, where VM2 did not. VM1 does work and our configuration is long term stable.
VM1 and VM2 cannot communicate.

[Tyler Bishop (tyler-bishop)]

Okay I was able to figure out the cause.

Steps to create:

1. Build VM
2. Disable security group: neutron port-update ec25360e-75e9-42fe-9491-013337f2768c --no-security-group
3. Disable port security rules: neutron port-update ec25360e-75e9-42fe-9491-013337f2768c --port-security-enabled=False
4. Live migrate VM to another hypervisor.

The port will now become broken, you can run disable again and it will correct it, however if you then live migrate the machine again it will break it and changing the port won't fix it.

[Tyler Bishop (tyler-bishop)]

Unable to get iptable rules to change once the port is migrated to a new hypervisor.

[Sreenivas (sreenivas-pothukanoori)]

Currently I am working on some other Kilo bug. So I dont want to upgrade my openstack setup from Kilo to Liberty version. Once I upgrade my setup to Liberty and if the bug is not assigned to anyone, ill pick and work on this bug.

[Zane Mingee (zmingee)]

Just some backstory, I work for Tyler Bishop as our Sr Software Engineer

I've been doing some testing on this issue in our testing cluster and I found the cause. In neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent:OVSNeutronAgent.treat_devices_added_or_updated:1402-1405, there is logic that is used to determine if a port is a "security_disabled_device".

This logic has an error at 1403 where it checks to see if the key "security_groups" exists in the details of the port, and if it does then it assumes that means that it has a security group. This is flawed, because if you remove all security groups then the key is still there, it just has an empty list as it's value. I've corrected this to check the length of the list instead.

The second issue is that the if statement checks if EITHER value of port_security and has_sgs is disabled, and if so then add it to "security_disabled_devices". The problem is that if you want to disable port security on a VM, you must remove all security groups and then disable port security. The way the logic is structured now will mean that iptables rules do not get propogated down the chain of calls when you get to neutron/agent/securitygroups_rpc.py and neutron/api/rpc/handlers/securitygroups_rpc.py.

After making my changes, connectivity to the VM survives after a service restart and live migration.

[Zane Mingee (zmingee)]

I had the wrong format for my patch. Here is the correct diff

[Zane Mingee (zmingee)]

I've changed my fix to an exclusive-OR to fix an issue with false-positives.

[Federico Iezzi (fiezzi)]

Hi there,

This bug to me seems something that should to be merged into the master but till now there is not fix in the master branch (and of course in any of the previous neutron's releases).
Can someone submit a patch?

[Tyler Bishop (tyler-bishop)]

The fix I submitted breaks other feature... Unsure how to fix correctly.

Sent from TypeApp

On Aug 9, 2016, 10:41 AM, at 10:41 AM, Federico Iezzi <email address hidden> wrote:
>Hi there,
>
>This bug to me seems something that should to be merged into the master
>but till now there is not fix in the master branch (and of course in
>any of the previous neutron's releases).
>Can someone submit a patch?
>
>--
>You received this bug notification because you are subscribed to the
>bug
>report.
>https://bugs.launchpad.net/bugs/1549443
>
>Title:
> Port Security does not consistently update nova iptables
>
>Status in neutron:
> Fix Committed
>
>Bug description:
> I have created a network with port security set to enabled. I have
> set --no-security-group and --port_security_enabled=False on the port
> however the iptables on the hypervisor is not consistently set.
>
> I have 2 VM on this hypervisors:
>
> VM1:
> tap0cc26c65-d1
>
> VM2:
> tap672dbe42-10
>
> Dump of iptables save:
> -A INPUT -j neutron-openvswi-INPUT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> -A FORWARD -j neutron-filter-top
> -A FORWARD -j neutron-openvswi-FORWARD
> -A FORWARD -j REJECT --reject-with icmp-host-prohibited
> -A OUTPUT -j neutron-filter-top
> -A OUTPUT -j neutron-openvswi-OUTPUT
> -A OUTPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT
> -A neutron-filter-top -j neutron-openvswi-local
>-A neutron-openvswi-FORWARD -m physdev --physdev-out tap85e24fb1-61
>--physdev-is-bridged -m comment --comment "Direct traffic from the VM
>interface to the security group chain." -j neutron-openvswi-sg-chain
>-A neutron-openvswi-FORWARD -m physdev --physdev-in tap85e24fb1-61
>--physdev-is-bridged -m comment --comment "Direct traffic from the VM
>interface to the security group chain." -j neutron-openvswi-sg-chain
>-A neutron-openvswi-FORWARD -m physdev --physdev-out tap1fe43774-ef
>--physdev-is-bridged -m comment --comment "Direct traffic from the VM
>interface to the security group chain." -j neutron-openvswi-sg-chain
>-A neutron-openvswi-FORWARD -m physdev --physdev-in tap1fe43774-ef
>--physdev-is-bridged -m comment --comment "Direct traffic from the VM
>interface to the security group chain." -j neutron-openvswi-sg-chain
>-A neutron-openvswi-FORWARD -m physdev --physdev-out tap0cc26c65-d1
>--physdev-is-bridged -m comment --comment "Accept all packets when port
>security is disabled." -j ACCEPT
>-A neutron-openvswi-FORWARD -m physdev --physdev-in tap0cc26c65-d1
>--physdev-is-bridged -m comment --comment "Accept all packets when port
>security is disabled." -j ACCEPT
>-A neutron-openvswi-INPUT -m physdev --physdev-in tap85e24fb1-61
>--physdev-is-bridged -m comment --comment "Direct incoming traffic from
>VM to the security group chain." -j neutron-openvswi-o85e24fb1-6
>-A neutron-openvswi-INPUT -m physdev --physdev-in tap1fe43774-ef
>--physdev-is-bridged -m comment --comment "Direct incoming traffic from
>VM to the security group chain." -j neutron-openvswi-o1fe43774-e
>-A neutron-openv...

[Tyler Bishop (tyler-bishop)]

Has anyone validated if this is corrected in mitaka?

[Thomas Edgar (twedgar)]

I can confirm that this bug still exists in mitaka. When we create a port with security disabled it doesn't get the appropriate iptables rules and when we do a port update to turn off port security the iptable rules are created.

[Thomas Edgar (twedgar)]

The posted patch did not work for us and we have been troubleshooting to find where the problem is and we think there may be a deviation of expectations in ml2 driver agent and neutron agent. In iptables_firewall the agent is managing all of the ports with two lists; unfiltered and filtered ports. filtered ports get the IPtable chains applied from the security groups as normal. Unfiltered get applied the three pass through rules specified in the initial bug post. However, the ml2 agent is removing port security disabled ports from the list of managed ports and thus they never get the three rules added. We made the attached change and things seem to be working in all our tests. This fix doesn't refactor out unnecessary code if the ml2 driver truly does not need to be filtering out ports any longer. We are running Mitaka and haven't looked to see if the scenario is the same for Liberty.

[Tyler Bishop (tyler-bishop)]

How do we get this merged into master?

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/425812

[Kevin Benton (kevinbenton)]

I would like to get this in Ocata because it leads to some pretty inconsistent behavior depending on the deployment's iptables defaults.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/421832
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=a8b6a597b6aab7cd3b0a5d0c3baad75af395fe1d
Submitter: Jenkins
Branch: master

commit a8b6a597b6aab7cd3b0a5d0c3baad75af395fe1d
Author: Bernard Cafarelli <email address hidden>
Date: Thu Jan 19 14:14:12 2017 +0100

    Revert "Setup firewall filters only for required ports"

    This reverts commit 75edc1ff28a460342a9b5e5b7d63c6f4fb59862d.

    Ports with port security disabled require firewall entries in
    neutron-openvswi-FORWARD chain to work properly.
    Ports created with no security groups will not get skipped with current
    code.
    With fixed security groups check, these ports' security groups can not
    be updated after creation.

    Change-Id: I95ddbe38d8ac8a927a860a98f54e41e17fb71d43
    Closes-Bug: #1549443

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/428073

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/428073
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=283270b3f91f731a4a89b2fb9d57a23327848951
Submitter: Jenkins
Branch: stable/newton

commit 283270b3f91f731a4a89b2fb9d57a23327848951
Author: Bernard Cafarelli <email address hidden>
Date: Thu Jan 19 14:14:12 2017 +0100

    Revert "Setup firewall filters only for required ports"

    This reverts commit 75edc1ff28a460342a9b5e5b7d63c6f4fb59862d.

    Ports with port security disabled require firewall entries in
    neutron-openvswi-FORWARD chain to work properly.
    Ports created with no security groups will not get skipped with current
    code.
    With fixed security groups check, these ports' security groups can not
    be updated after creation.

    Closes-Bug: #1549443

    Conflicts:
     neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
     neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/test_ovs_neutron_agent.py

    Change-Id: I95ddbe38d8ac8a927a860a98f54e41e17fb71d43
    (cherry picked from commit a8b6a597b6aab7cd3b0a5d0c3baad75af395fe1d)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/425812
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2725b4d3140be526f9662082958ef82d1d3ebeef
Submitter: Jenkins
Branch: master

commit 2725b4d3140be526f9662082958ef82d1d3ebeef
Author: Daniel Alvarez <email address hidden>
Date: Mon Jan 16 02:55:08 2017 +0000

    Include port_security check in fullstack tests

    Bug #1549443 skipped setting up the right firewall rules for ports
    created with port security disabled. This bug was not caught since
    tests didn't cover this fact.

    This patch adds functionality to existing test by creating ports with
    port_security_enabled=False and checking that traffic is allowed prior
    to enabling port security and assigning security groups to them.

    Change-Id: I65da39fd390e4faecc6cfb18bb50e1f5ce684f1e
    Related-Bug: #1549443

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 10.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/440850

[Akihiro Motoki (amotoki)]

This bug causes security issue. It is worth backported to Mitaka too.

As reported in the initial bug report, when creating a port with no security group or with port_security_enabled=False and then booting a VM with the port, iptables rules for the VM are not configured properly. As a result, VM traffic is handled based on the default FORWARD policy of the hypervisor host. It is confusing.

There is another issue. Once this situation happens, even after a user change the port to port_security_enabled=True or associate security group to the port, corresponding iptables rules are not installed. This means security group is not applied to the port. Neutron API says security group is applied but actually no security group is applied.

[Akihiro Motoki (amotoki)]

It looks worth backported to mitaka even though mitaka is now in "Only security patches are acceptable" phase.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/440850
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=3d146d0e79c5411f7b156cae2085b17ef10d671f
Submitter: Jenkins
Branch: stable/mitaka

commit 3d146d0e79c5411f7b156cae2085b17ef10d671f
Author: Bernard Cafarelli <email address hidden>
Date: Thu Jan 19 14:14:12 2017 +0100

    Revert "Setup firewall filters only for required ports"

    This reverts commit 75edc1ff28a460342a9b5e5b7d63c6f4fb59862d.

    Ports with port security disabled require firewall entries in
    neutron-openvswi-FORWARD chain to work properly.
    Ports created with no security groups will not get skipped with current
    code.
    With fixed security groups check, these ports' security groups can not
    be updated after creation.

    Closes-Bug: #1549443

    Conflicts:
     neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
     neutron/tests/functional/agent/l2/base.py
     neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/test_ovs_neutron_agent.py

    Change-Id: I95ddbe38d8ac8a927a860a98f54e41e17fb71d43
    (cherry picked from commit a8b6a597b6aab7cd3b0a5d0c3baad75af395fe1d)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 9.3.0 release.