Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1605606 - Neutron port security blocking DHCP for external networks configured with --no-dhcp
Summary: Neutron port security blocking DHCP for external networks configured with --n...
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Slawek Kaplonski
QA Contact: Toni Freger
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-20 16:13 UTC by Nenad Peric
Modified: 2019-03-18 05:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: There is was to use external DHCP server for an instance in a neutron provider network with enabled port_security by adding specific security group rule for such port. Such rule can be created like: neutron security-group-rule-create <sec_group_id> --direction ingress --protocol udp --port-range-min 68 --port-range-max 68 Reason: Currently there is described possibility to use external DHCP server for an instance in a neutron provider network but it tells to disable port_security completely. So no security groups can be used on such port. It is described in https://access.redhat.com/solutions/2428301 Result: After adding such sec group rule user will be able to use external DHCP service for an instance and also he still be able to use security groups to block some other traffic to such instance.
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1785213 None None None 2018-08-03 10:25:24 UTC

Description Nenad Peric 2018-07-20 16:13:02 UTC
Description of problem:

When configuring provider flat network with --no-dhcp option, the port security is still completely enabled, blocking external DHCP server from replying to VMs requesting the IP. 

When port security was disabled on the port, the instance got the address immediately. 


Network was created as follows:

network create --share --external --provider-physical-network datacentre --provider-network-type flat --default external

subnet create --dns-nameserver x.x.x.1 --dns-nameserver x.x.x.120 --allocation-pool start=x.x.x.20,end=x.x.x.30 --network external --no-dhcp --gateway x.x.x.126 --subnet-range x.x.x.0/25 external_subnet



Version-Release number of selected component (if applicable):

OSP 13 (Queens)


Actual results:

Instance does not get an IP address and thus remains inaccessible.

Expected results:

Even with port security enabled, dhcp filter could be disabled in this case. 
Instance should be able to get the IP address when attached directly to an external network. 


Additional info:

Comment 3 Slawek Kaplonski 2018-07-24 15:47:30 UTC
So I think I found an issue. Currently iptables_hybrid driver adds properly rules to allow outgoing DHCP requests from instance to be send to external network. It's in https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L443
And indeed requests are going out from compute node and can reach external DHCP server as it was in my tests.
But problem is that response, which looks like:

17:24:30.961345 52:54:00:10:96:39 > fa:16:3e:de:81:7c, ethertype IPv4 (0x0800), length 354: 10.0.0.1.67 > 10.0.0.212.68: BOOTP/DHCP, Reply, length 312

can't go back as there is missing proper rule in ingress chain for port.

So adding something like:

iptables -I neutron-openvswi-i378ab5a0-8 -p udp -m udp --sport 67 --dport 68 -j RETURN

solved this issue on my dev environment.


Now the question is: do we want to allow such traffic by default for every port and it should be added in security group rules in this case, like:

neutron security-group-rule-create 9d081ca9-2fa3-46d9-8854-b92f017598d1 --direction ingress --protocol udp --port-range-min 68 --port-range-max 68

Comment 4 Nenad Peric 2018-07-26 11:36:58 UTC
So on the compute which hosted the instance (VM) I ran:

 iptables -I neutron-openvswi-i69ec79bc-1 -p udp -m udp --sport 67 --dport 68 -j RETURN

and I received an Ip after restarting the network, so the DHCP packets arrived. 

That worked. 

That would make sens as a default only for this type of network. Because if you attach your VM directly to an externally managed network, you would expect this part (DHCP addressing, cloud-init etc..) to work as well I suppose?

If this cannot be easily separated separated internally, can it be a tunable with an argument? Like --external-dhcp or similar during network creation? 

Worst case scenario, this can be added as a step in docs so that people manually create it on the network subnet, or inside the security group they use (not sure here about precedence as far as security group vs port security goes)

Comment 7 Slawek Kaplonski 2018-11-13 16:25:54 UTC
Upstream RFE was discussed on Neutron drivers team meeting some time ago. It was decided there that this might be implemented if there will be more interested from community to get something like that.
I sent email to operators about that: http://lists.openstack.org/pipermail/openstack-operators/2018-October/016125.html but there was no feedback about that.
So I assume that there is no such need in community.
As long as this might be easily workaround by adding proper security group rule for port now, I think we can close this BZ for now.

Comment 8 Nenad Peric 2018-11-13 17:01:39 UTC
Ok, sounds good. 

As long as the workaround with security groups work, it should be fine. 

Not sure if that should or shouldn't be documented someplace though. 
I mean the very fact that DHCP from outside is not going to get inside. 

Anyway, adding one more rule to the security group should not be a big issue, and generally fixes the problem for those who really need to fix it. 

Thanks!!


Note You need to log in before you can comment on or make changes to this bug.