Bug 919181
| Summary: | Quantum router is not responding to ICMP from VMs becuase of iptables rules | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Ofer Blaut <oblaut> | ||||||
| Component: | openstack-neutron | Assignee: | Bob Kukura <rkukura> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Ofer Blaut <oblaut> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 2.0 (Folsom) | CC: | ajeain, breeler, chrisw, cnegus, jkt, lpeer, ppyy, sgordon | ||||||
| Target Milestone: | async | Keywords: | Triaged | ||||||
| Target Release: | 4.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Known Issue | |||||||
| Doc Text: |
The quantum-l3-agent does not create firewall rules to allow traffic to be forwarded between its interface and gateway ports, and the Red Hat Enterprise Linux firewall's FORWARD chain rejects traffic by default. As a consequence, traffic between virtual machines and the external network is not forwarded.
A workaround is to add the following iptable rules on each note hosting the quantum-l3-agent service:
# iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT
# iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT
# iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT
# service iptables save
This allows traffic to be forwarded as expected.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-11-06 11:53:49 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: | |||||||||
| Attachments: |
|
||||||||
Gary, what rules need to be added for this? Are you sure this hasn't been fixed? We don't want to simply forward everything, do we? I've found adding the following rules on the quantum-l3-agent node allows the router to forward outgoing traffic from VMs to the external network and incoming traffic from the external networks to VMs (with floating IPs): iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT The last rule should allow traffic to be routed from between different private networks connected to the router, but have not tested that yet. I've added "known issue" doc text describing the workaround. This bug should be left open until either the quantum-l3-agent or quantum-l3-setup is fixed to create the needed firewall rules automatically. Created attachment 737177 [details]
Summary of 4 interrelated bugs' Doc Texts
@ Bob, this bug seems to be almost identical to BZ920638, in terms of the Doc Text at least. But whereas this bug gives 3 iptable entries, without conditions, BZ920638 has one iptable entry, but it is conditional on using nova-security groups. BZ920638's Doc Text: =========== If using nova security groups, add the following iptables rule on each compute node: iptables -t filter -I FORWARD -i qbr+ -o qbr+ -j ACCEPT service iptables save Either reboot or restart nova-compute after adding this rule, since the rules nova-compute adds at startup must precede this rule. If not using nova security groups, an alternative solution is to set libvirt_vif_driver = nova.virt.libvirt.vif.LibvirtOpenVswitchVirtualPortDriver ============ I have added both bugs' Doc Texts to Rel Notes for now, but wonder if these could be consolidated. In addition, BZ918087 and BZ928815 are also similar. I have attached a txt file summarising the doc texts for these 4 bugs as I feel they could probably be consolidated? Both this bug and BZ 920638 do recommend creating similar-looking firewall rules, but these apply to different flows of traffic on different types of nodes, and the same rules do not address both situations. This bug applies to traffic flowing through the L3 router, and the rules it recommends are only needed on nodes where the quantum-l3-agent is deployed. BZ 920638 applies to traffic flowing through the "hybrid bridge" used to implement security groups with the openvswitch plugin. Those rules are needed on nodes where nova-compute is deployed. I think keeping these two as separate release notes makes the most sense since they apply in different situations. But you are correct that the four bugs you cite are related. I believe Chris Negus is or will be working on a knowledge base article or two addressing the full set of issues/limitations related to iptables and network namespaces. The article is not yet published. I added a reference to this bug in the article, which you can find here: https://access.redhat.com/site/articles/339573 This issue was resolved in Grizzly and Havana It works on both versions closing the issue Resolved in Havana. |
Created attachment 706772 [details] FORWARD rules Description of problem: Quantum router is not responding to ICMP from VMs becuase of iptables rules The rule reject the ICMP packets This is not happening in NOVA NETWORK attached NOVA vs Quantum FORWARD Rules Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. create quantum setup with router 2. check VM got default GW via DHCP 3. ping default GW 4. check iptables -L FORWARD -n -v ( check what drops the packets ) 5. stop ip tables and see it works Actual results: Expected results: Additional info: