# Revision history [back]

### Security Group Problem: GRE

Hi, I am trying to run OpenStack in VMs that themselves are hosted by OpenStack. I'll call those OpenStack clouds "inner" and "outer" in the following.

The inner and outer cloud uses Neutron via Open vSwitch and GRE. The outer cloud works perfectly fine but the inner cloud has trouble establishing GRE tunnels from compute to network node. The symptom is that VMs on the inner cloud send DHCP requests but never receive an IP. I can sniff, for example, the inner compute node's eth1 interface and can see GRE traffic with embedded DHCP passing through. Nothing is received on the network node side though.

Our guess was that Security Groups are probably blocking GRE traffic, so we added rules to the group:

mewald@kvm00:~$neutron security-group-show allow-all +----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | description | Security group to allow all traffic. | | id | 6410c492-3ba1-4fce-ae89-3dbe0c467c54 | | name | allow-all | | security_group_rules | {"remote_group_id": null, "direction": "ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "icmp", "tenant_id": "20c3cafe9741418a8f76f4697d247090", "port_range_max": null, "security_group_id": "6410c492-3ba1-4fce-ae89-3dbe0c467c54", "port_range_min": null, "ethertype": "IPv4", "id": "0b905a1c-8a5b-4864-9d36-30c282f4e6e4"} | | | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": null, "protocol": null, "tenant_id": "20c3cafe9741418a8f76f4697d247090", "port_range_max": null, "security_group_id": "6410c492-3ba1-4fce-ae89-3dbe0c467c54", "port_range_min": null, "ethertype": "IPv4", "id": "344c1877-0036-4a9f-b53c-d36a918a1c20"} | | | {"remote_group_id": null, "direction": "ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol": null, "tenant_id": "20c3cafe9741418a8f76f4697d247090", "port_range_max": null, "security_group_id": "6410c492-3ba1-4fce-ae89-3dbe0c467c54", "port_range_min": null, "ethertype": "IPv4", "id": "43180a08-ff23-4a9a-8e87-c386a50f974d"} | | | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "icmp", "tenant_id": "20c3cafe9741418a8f76f4697d247090", "port_range_max": null, "security_group_id": "6410c492-3ba1-4fce-ae89-3dbe0c467c54", "port_range_min": null, "ethertype": "IPv4", "id": "4b215c72-7174-4230-b680-8e7edbbabc03"} | | | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "47", "tenant_id": "20c3cafe9741418a8f76f4697d247090", "port_range_max": null, "security_group_id": "6410c492-3ba1-4fce-ae89-3dbe0c467c54", "port_range_min": null, "ethertype": "IPv4", "id": "58521f7c-72e6-436b-8fdc-ed590e81ca95"} | | | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "4", "tenant_id": "20c3cafe9741418a8f76f4697d247090", "port_range_max": null, "security_group_id": "6410c492-3ba1-4fce-ae89-3dbe0c467c54", "port_range_min": null, "ethertype": "IPv4", "id": "8bd5890e-c878-43ca-b7f3-da50860ece9b"} | | | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": null, "protocol": null, "tenant_id": "20c3cafe9741418a8f76f4697d247090", "port_range_max": null, "security_group_id": "6410c492-3ba1-4fce-ae89-3dbe0c467c54", "port_range_min": null, "ethertype": "IPv6", "id": "a129b40c-c8d2-4d73-b72a-0a6108a39747"} | | | {"remote_group_id": null, "direction": "ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "4", "tenant_id": "20c3cafe9741418a8f76f4697d247090", "port_range_max": null, "security_group_id": "6410c492-3ba1-4fce-ae89-3dbe0c467c54", "port_range_min": null, "ethertype": "IPv4", "id": "d56fa230-03aa-4c58-a29e-75c2813da67c"} | | | {"remote_group_id": null, "direction": "ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "47", "tenant_id": "20c3cafe9741418a8f76f4697d247090", "port_range_max": null, "security_group_id": "6410c492-3ba1-4fce-ae89-3dbe0c467c54", "port_range_min": null, "ethertype": "IPv4", "id": "f9264dff-4059-4721-b5ab-0cb7bf946dd5"} | | tenant_id | 20c3cafe9741418a8f76f4697d247090 | +----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ mewald@kvm00:~$


I can see that the last rule allows protocol 47 which is the protocol number of GRE.

As soon as I execute

iptables -I FORWARD 1 -j ACCEPT


all traffic flows normally in the inner cloud allowing VMs to receive DHCP. I dug deeper into iptables and found that the proto 47 rule is actually established. It looks like this for examples:

Chain neutron-openvswi-i74c08eef-a (1 references)
pkts bytes target     prot opt in     out     source               destination
0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID /* Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack. */
0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED /* Direct packets associated with a known session to the RETURN chain. */
0     0 RETURN     udp  --  *      *       203.0.113.10         0.0.0.0/0            udp spt:67 dpt:68
0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
0     0 RETURN     4    --  *      *       0.0.0.0/0            0.0.0.0/0
0     0 RETURN     47   --  *      *       0.0.0.0/0            0.0.0.0/0
0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set NETIPv4b7a28a05-33bd-4f17-9 src
0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            match-set NETIPv4b7a28a05-33bd-4f17-9 src
0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
0     0 neutron-openvswi-sg-fallback  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* Send unmatched traffic to the fallback chain. */


Unfortunately, I dont know how to map the chain name to the instance but there are several chains with this rule so I assume it was set up as expected.

Now I would like to find out why the rule does not allow my GRE traffic in the inner cloud?! Any ideas?