Bug 1100993

Summary: packstack should open Tunnel ports VXLAN and GRE
Product: Red Hat OpenStack Reporter: Ofer Blaut <oblaut>
Component: openstack-packstackAssignee: Lukas Bezdicka <lbezdick>
Status: CLOSED ERRATA QA Contact: Ofer Blaut <oblaut>
Severity: medium Docs Contact:
Priority: high    
Version: 5.0 (RHEL 7)CC: adahms, aortega, derekh, ichavero, lars, lbezdick, lpeer, mburns, mmagr, nyechiel, oblaut, sclewis, yeylon
Target Milestone: rc   
Target Release: 5.0 (RHEL 7)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-packstack-2014.1.1-0.21.dev1116.el7ost Doc Type: Bug Fix
Doc Text:
Previously, virtual machines in a Red Hat OpenStack environment configured using the PackStack all-in-one installation process would have no network connectivity under certain circumstances. This was caused by the logic used in the PackStack all-in-one installation process, whereby the VXLAN and GRE ports required for virtual machine network connectivity would not be opened in the firewall. Now, this logic has been revised so that these ports are opened correctly during the PackStack all-in-one installation process, making it possible for virtual machines to communicate over the network without having to manually configure the firewall.
 Story Points: ---
Clone Of:
: 1111640 (view as bug list) Environment:
Last Closed: 2014-07-08 15:38:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1111640    

Description Ofer Blaut 2014-05-25 06:19:05 UTC 
Description of problem:


Packstack doesn't open VXLAN UDP port 4789 on hosts

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


How reproducible:


Steps to Reproduce:
1.configure iptables default policy to DROP  - iptables -P INPUT DROP
2.configure setup with VXLAN support
3.Run few VMs and check they didn't get IP 
4. add iptable rule on all hosts and restart the VM to see DHCP is working


Actual results:

VMs will not get DHCP and access to the networks 

Expected results:


Additional info:

Foreman does open VXLAN port, issue might be on RHEL_OSP 4 as well

workaround:

iptables -A INPUT -p udp --dport 4789 -j ACCEPT

iptables-save > /etc/sysconfig/iptables
Comment 1 Ofer Blaut 2014-05-27 10:22:49 UTC 
Packstack should open GRE as well


Workaround 

iptables -A INPUT  -p 47  -j ACCEPT
Comment 2 Nir Yechiel 2014-05-28 11:53:37 UTC 
Ivan,

Can you please update the status of this?


Thanks,
Nir
Comment 3 Lars Kellogg-Stedman 2014-05-30 14:13:46 UTC 
*** Bug 1072325 has been marked as a duplicate of this bug. ***
Comment 4 Ivan Chavero 2014-06-01 00:42:20 UTC 
Patch merged, creating package.
Comment 7 Ofer Blaut 2014-06-03 06:56:21 UTC 
The VXLAN is using UDP and not TCP

reopen the bug

ACCEPT     tcp  --  10.35.160.17         0.0.0.0/0            multiport dports 4789 /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.17 */
ACCEPT     tcp  --  10.35.160.19         0.0.0.0/0            multiport dports 4789 /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.19 */
ACCEPT     tcp  --  10.35.160.77         0.0.0.0/0            multiport dports 4789 /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.77 */
ACCEPT     tcp  --  10.35.160.89         0.0.0.0/0            multiport dports 4789 /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.89 */


openstack-packstack-2014.1.1-0.19.dev1102.el7ost.noarch
Comment 8 Miguel Angel Ajo 2014-06-03 10:21:01 UTC 
please use this as a workaround (iptables -A didn't work for me)

iptables -I INPUT -p udp --dport 4789 -j ACCEPT
iptables -I INPUT  -p 47  -j ACCEPT
iptables-save > /etc/sysconfig/iptables

explanation: iptables -A INPUT adds the rule at bottom, while iptables -I INPUT adds the rule at top of all input rules.
Comment 10 Ofer Blaut 2014-06-03 11:25:41 UTC 
GRE works fine 

ACCEPT     47   --  10.35.160.17         0.0.0.0/0            /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.17 */
ACCEPT     47   --  10.35.160.19         0.0.0.0/0            /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.19 */
ACCEPT     47   --  10.35.160.77         0.0.0.0/0            /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.77 */
ACCEPT     47   --  10.35.160.89         0.0.0.0/0            /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.89 */
Comment 11 Alvaro Lopez Ortega 2014-06-03 13:51:16 UTC 
Martin is currently working on it
Comment 13 Ofer Blaut 2014-06-05 05:22:30 UTC 
Tested 

ACCEPT     udp  --  10.35.160.17         0.0.0.0/0            multiport dports 4789 /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.17 */
ACCEPT     udp  --  10.35.160.19         0.0.0.0/0            multiport dports 4789 /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.19 */
ACCEPT     udp  --  10.35.160.77         0.0.0.0/0            multiport dports 4789 /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.77 */
ACCEPT     udp  --  10.35.160.89         0.0.0.0/0            multiport dports 4789 /* 001 neutron tunnel port incoming neutron_tunnel_10.35.160.19_10.35.160.89 */
openstack-packstack-2014.1.1-0.20.dev1109.el7ost.noarch
Comment 14 Ofer Blaut 2014-06-05 06:02:52 UTC 
Hi

I have missed the source ip of the Tunnels (traffic fails)
so bug is re-opened (My workaround used iptables -A INPUT -p udp --dport 4789 -j ACCEPT without source ips )

The source ip in the iptables should be the ones of the Tunnel-Interfaces used for VXLAN.( not the host management ip address ), we might need to add Subnet here or other solution.

On my setup

management interfaces : 10.35.160.X
Tunnel interface:  55.55.55.X



[root@puma05 ~]# tcpdump -ni  enp4s0f1 udp port 4789
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp4s0f1, link-type EN10MB (Ethernet), capture size 65535 bytes
08:57:31.775203 IP 55.55.55.77.36818 > 55.55.55.19.4789: VXLAN, flags [I] (0x08), vni 20000
IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
08:57:31.913356 IP 55.55.55.77.60182 > 55.55.55.19.4789: VXLAN, flags [I] (0x08), vni 20000
IP6 :: > ff02::1:ff9b:2b3e: ICMP6, neighbor solicitation, who has fe80::f816:3eff:fe9b:2b3e, length 24
08:57:32.913339 IP 55.55.55.77.59250 > 55.55.55.19.4789: VXLAN, flags [I] (0x08), vni 20000
IP6 fe80::f816:3eff:fe9b:2b3e > ff02::2: ICMP6, router solicitation, length 16
Comment 15 Ofer Blaut 2014-06-05 14:37:58 UTC 
Since packstack DOES check if IP is configured on each tunnel interface on the hosts it can know the exact ip address he need to use
Comment 16 Lars Kellogg-Stedman 2014-06-05 18:40:29 UTC 
Ofer:

The only place packstack knows the ip address of NEUTRON_OVS_TUNNEL_IF is when it is actually running Puppet manifests on that node.  There's no mechanism to communicate these addresses back to the controller in order to prepare an ip-address based firewall rule.

The best we could do is to restrict access to traffic inbound on that particular interface.  That is, instead of:

  iptables -I INPUT -p udp --dport 4789 -j ACCEPT

Do something like:

  iptables -I INPUT -i eth1 -p udp --dport 4789 -j ACCEPT
Comment 17 Ofer Blaut 2014-06-08 06:21:18 UTC 
tested 

openstack-packstack-2014.1.1-0.22.dev1117.el7ost.noarch
openstack-packstack-puppet-2014.1.1-0.22.dev1117.el7ost.noarch
openstack-packstack-doc-2014.1.1-0.22.dev1117.el7ost.noarch

Works with traffic 

[root@puma04 ~(keystone_admin)]# iptables -nL | grep 4789
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 4789 /* 001 neutron tunnel port incoming neutron_tunnel */
Comment 22 errata-xmlrpc 2014-07-08 15:38:45 UTC 
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.

http://rhn.redhat.com/errata/RHEA-2014-0846.html