Description of problem: - If you want to serve DHCP from an instance (not for an instance but from), then you need to manually edit the iptables chain which implements that instance's security group as described in https://access.redhat.com/solutions/1276853 - The security group can have an explicit allow of all UDP traffic, yet still have an unseen (as per neutron security-group-show) drop of UDP:{67,68} - I assume the unseen rules are from the security group's feature to prohibit, IP, DHCP, and MAC address spoofing - However, there are legitimate cases where the admin should be able to override those rules Version-Release number of selected component (if applicable): - openstack-neutron-2014.1.3-7.el7ost.noarch How reproducible: - Deterministic Steps to Reproduce: - packstack an openstack instance - add a flat provider network (https://access.redhat.com/solutions/1242873) - configure an instance to serve DHCP - configure a rule in the security group to allow all UDP traffic - configure a server on the same L2 network but external to openstack as a DHCP client - try to have the DHCP client get an address Actual results: - DHCP conversation will DHCPDISCOVER, DHCPOFFER; but not DHCPREQUEST nor DHCPACK Expected results: - `neutron security-group-show $ID` does not hide anti-spoofing rules which can be seen with with `iptables -L neutron-openvswi-_____` - neutron supports a command line option to disable the anti-spoofing rules Workaround: - directly modify the security group's iptables to not drop UDP:{67,68} as described in https://access.redhat.com/solutions/1276853
The problem are the unconditional egress_rules which are added to every port here: _add_fixed_egress_rules https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L362 _drop_dhcp_rule: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L277 I suppose the idea is enforcing those rules, even if this was set on security groups instead and the tenant removed it (in the context of shared networks with other tenants). May be an option could be to disable this by a flag, on specific ports by admin or completely when the port is not connected to a shared network (then the tenant can be responsible of his own security groups).
Adding a link to the u/s spec for implementing this. The spec is approved for Kilo and is not available as part of the Juno release(which is the release OSP-6 is based on).
Terry - can you please take a look what is the status os this feature. Is it available in Kilo?
*** Bug 1109456 has been marked as a duplicate of this bug. ***
This feature has been committed upstream Neutron. python-neutronclient does not appear to have been updated to allow port_security_enabled=False to be passed during network/port creates/updates.
(In reply to Terry Wilson from comment #9) > This feature has been committed upstream Neutron. python-neutronclient does > not appear to have been updated to allow port_security_enabled=False to be > passed during network/port creates/updates. Terry can you submit the patch to neutronclient to enable this?
> Terry can you submit the patch to neutronclient to enable this? lpeer: Something must have been messed up with my setup, because after researching how to add this, it seems to already be working now. [vagrant@localhost devstack]$ neutron net-create --port-security-enabled=False mynet Created a new network: +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | id | 008fa245-34a3-4c2e-81aa-2912060071bc | | mtu | 0 | | name | mynet | | port_security_enabled | False |<-- | provider:network_type | vxlan | | provider:physical_network | | | provider:segmentation_id | 1003 | | router:external | False | | shared | False | | status | ACTIVE | | subnets | | | tenant_id | f7c2ea32db8f46c48c10bca7c5ed3211 | | vlan_transparent | False | +---------------------------+--------------------------------------+ Tested with net/port create/update and all seem to work.
Terry , I finished to write the test plan and I attached it to "External Trackers". Please take a look and tell me if you have any comments .
Eran: There appear to be 3 test cases. Am I reviewing all 3 or just one of them? The user member role stuff still mentions creating user roles, since 'network creator' is based on the tenant, and doesn't have anything to do with user roles this test will always fail. I see a note in one of the test cases, but not the others--so those probably need updating/that section could be deleted or changed to specify testing on 'public' shared networks and different tenants. As far as the mac spoofing stuff goes, I may not be qualified to comment as I haven't ever tried spoofing a mac address on a VM before today. I've gone through an abbreviated version of the test with devstack, just launching two VMs on the same host with the default settings and logging in and following the instructions to spoof the mac address on VM1. VM1 is still able to ssh to VM2, even though port security is enabled. So I'm not sure the given test is sufficient to test the port security feature. Test performed: 1) Standard devstack single network basic setup: https://wiki.openstack.org/wiki/NeutronDevstack 2) nova boot --image cirros-0.3.4-x86_64-uec --flavor 1 --nic net-id=$(neutron net-show -F id -f value private) --num-instances=2 test 3) nova get-vnc-console test1 novnc 4) Through console, test connectivity to VM2 # SUCCESS 5) Through console, complete step 11 for mac spoofing: https://tcms.engineering.redhat.com/case/478418/ # SSH still successful If I'm misunderstanding something/doing something wrong and you get a negative result w/o setting port-security-enabled=False, go for it. If not, we'll have to figure something else out.
Hi Terry . You need to review all 3 test cases. In my ENV I tested spoof mac address scenario and it worked as well I don't really understand what's the difference between what I did and what you ran. I will run the test again to verify it again .
Tested on Kilo 7.0-RHEL-7-Beta/2015-05-28.1 https://tcms.engineering.redhat.com/run/248627/
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2015:1548