Bug 889868 - dnsmasq DHCP request blocked by default firewall rules
dnsmasq DHCP request blocked by default firewall rules
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
2.0 (Folsom)
Unspecified Unspecified
high Severity high
: snapshot4
: 2.1
Assigned To: Gary Kotton
Ofer Blaut
: Triaged
Depends On:
Blocks: quantum_ovs_tracker
  Show dependency treegraph
Reported: 2012-12-23 12:40 EST by Chris Wright
Modified: 2016-04-26 12:57 EDT (History)
9 users (show)

See Also:
Fixed In Version: openstack-nova-2012.2.3-4.el6ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-03-21 14:14:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1129055 None None None Never
OpenStack gerrit 22183 None None None Never

  None (edit)
Description Chris Wright 2012-12-23 12:40:35 EST
In some cases, guests are unable to obtain a DHCP lease.  The issue is caused by default host firewall rules:

-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

The default INPUT rule to reject is triggering on the DHCP request and is therefore never seen by dnsmasq.  Simple workaround is to disable that rule, however that has negative security implications.  This has been reproduced with both OVS and LinuxBridge.
Comment 2 Ofer Blaut 2012-12-26 02:18:38 EST
Issue apears on RHEL 6.4 beta with nova based firewall rules

the workaround i have used is to disable firewall rule in /etc/nova/nova/conf  & reboot 

#firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver
firewall = nova.virt.firewall.NoopFirewallDriver

The Nova rules in my host:

instances i have used &

# Generated by iptables-save v1.4.7 on Wed Dec 26 10:50:19 2012
:PREROUTING ACCEPT [445522:23017910]
:OUTPUT ACCEPT [10947:1407803]
:nova-api-OUTPUT - [0:0]
:nova-api-POSTROUTING - [0:0]
:nova-api-PREROUTING - [0:0]
:nova-api-float-snat - [0:0]
:nova-api-snat - [0:0]
:nova-compute-OUTPUT - [0:0]
:nova-compute-POSTROUTING - [0:0]
:nova-compute-PREROUTING - [0:0]
:nova-compute-float-snat - [0:0]
:nova-compute-snat - [0:0]
:nova-postrouting-bottom - [0:0]
-A POSTROUTING -j nova-postrouting-bottom 
-A POSTROUTING -s ! -d -p tcp -j MASQUERADE --to-ports 1024-65535 
-A POSTROUTING -s ! -d -p udp -j MASQUERADE --to-ports 1024-65535 
-A OUTPUT -j nova-compute-OUTPUT 
-A OUTPUT -j nova-api-OUTPUT 
-A nova-api-snat -j nova-api-float-snat 
-A nova-compute-snat -j nova-compute-float-snat 
-A nova-postrouting-bottom -j nova-compute-snat 
-A nova-postrouting-bottom -j nova-api-snat 
# Completed on Wed Dec 26 10:50:19 2012
# Generated by iptables-save v1.4.7 on Wed Dec 26 10:50:19 2012
:PREROUTING ACCEPT [701113:107906116]
:INPUT ACCEPT [258278:85280778]
:FORWARD ACCEPT [9740:3055008]
:OUTPUT ACCEPT [209363:102737571]
:POSTROUTING ACCEPT [219446:105071947]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill 
# Completed on Wed Dec 26 10:50:19 2012
# Generated by iptables-save v1.4.7 on Wed Dec 26 10:50:19 2012
:INPUT ACCEPT [258219:85261900]
:FORWARD ACCEPT [9740:3055008]
:OUTPUT ACCEPT [206968:101910933]
:nova-api-FORWARD - [0:0]
:nova-api-INPUT - [0:0]
:nova-api-OUTPUT - [0:0]
:nova-api-local - [0:0]
:nova-compute-FORWARD - [0:0]
:nova-compute-INPUT - [0:0]
:nova-compute-OUTPUT - [0:0]
:nova-compute-inst-10 - [0:0]
:nova-compute-inst-9 - [0:0]
:nova-compute-local - [0:0]
:nova-compute-provider - [0:0]
:nova-compute-sg-fallback - [0:0]
:nova-filter-top - [0:0]
-A INPUT -j nova-compute-INPUT 
-A INPUT -j nova-api-INPUT 
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT 
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT 
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT 
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT 
-A FORWARD -j nova-filter-top 
-A FORWARD -j nova-compute-FORWARD 
-A FORWARD -j nova-api-FORWARD 
-A FORWARD -d -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -s -i virbr0 -j ACCEPT 
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT 
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable 
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable 
-A OUTPUT -j nova-filter-top 
-A OUTPUT -j nova-compute-OUTPUT 
-A OUTPUT -j nova-api-OUTPUT 
-A nova-api-INPUT -d -p tcp -m tcp --dport 8775 -j ACCEPT 
-A nova-compute-inst-10 -m state --state INVALID -j DROP 
-A nova-compute-inst-10 -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A nova-compute-inst-10 -j nova-compute-provider 
-A nova-compute-inst-10 -s -p udp -m udp --sport 67 --dport 68 -j ACCEPT 
-A nova-compute-inst-10 -s -j ACCEPT 
-A nova-compute-inst-10 -p icmp -j ACCEPT 
-A nova-compute-inst-10 -j nova-compute-sg-fallback 
-A nova-compute-inst-9 -m state --state INVALID -j DROP 
-A nova-compute-inst-9 -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A nova-compute-inst-9 -j nova-compute-provider 
-A nova-compute-inst-9 -s -p udp -m udp --sport 67 --dport 68 -j ACCEPT 
-A nova-compute-inst-9 -s -j ACCEPT 
-A nova-compute-inst-9 -p icmp -j ACCEPT 
-A nova-compute-inst-9 -j nova-compute-sg-fallback 
-A nova-compute-local -d -j nova-compute-inst-10 
-A nova-compute-local -d -j nova-compute-inst-9 
-A nova-compute-sg-fallback -j DROP
Comment 3 Bob Kukura 2013-02-11 11:38:05 EST
I've found the following work-around to allow the DHCP lease to succeed:

$ sudo cp /etc/sysconfig/iptables .
$ sudo chmod 666 iptables
edit iptables
 add the following to INPUT chain before final REJECT:
  -A INPUT -s -d -p udp -m udp --sport 68 --dport 67 -j ACCEPT
 add the following to FORWARD chain before final REJECT:
  -A FORWARD -s -d -p udp -m udp --sport 68 --dport 67 -j ACCEPT
$ sudo cp iptables /etc/sysconfig/
$ sudo iptables-restore < iptables

There probably belong in nova-compute-INPUT and nova-compute-FORWARD instead of the main INPUT and FORWARD chains. We also need to determine whether either or both of these rules are needed on a quantum network node where quantum-dhcp-agent runs in addition to or instead of on the compute nodes.
Comment 14 Ofer Blaut 2013-03-06 07:07:45 EST
Tested on 
Comment 16 errata-xmlrpc 2013-03-21 14:14:22 EDT
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.


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