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
Packstack should open GRE as well Workaround iptables -A INPUT -p 47 -j ACCEPT
Ivan, Can you please update the status of this? Thanks, Nir
*** Bug 1072325 has been marked as a duplicate of this bug. ***
Patch merged, creating package.
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
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.
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 */
Martin is currently working on it
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
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
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
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
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 */
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