Bug 427443

Summary: iptables state target breaks when running as DomU
Product: Red Hat Enterprise Linux 4 Reporter: Andreas Thienemann <athienem>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED DUPLICATE QA Contact: Martin Jenner <mjenner>
Severity: low Docs Contact:
Priority: low    
Version: 4.6CC: ddutile, xen-maint
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-13 09:35:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andreas Thienemann 2008-01-03 20:31:04 UTC
Description of problem:
After moving a machine from a vmware environment into a xen environment some
services on the new DomU are unavailable from other virtualized machines running
on the same Dom0 host.

tcpdump shows the following traffic on the shared xenbr0.

21:05:01.579509 IP 192.168.176.130.49890 > 192.168.176.20.http: S
3974247404:3974247404(0) win 5840 <mss 1460,sackOK,timestamp 241035 0,nop,wscale 7>
21:05:01.579570 IP 192.168.176.20.http > 192.168.176.130.49890: S
757456538:757456538(0) ack 3974247405 win 5792 <mss 1460,sackOK,timestamp
2028417 241035,nop,wscale 2>
21:05:01.579620 IP 192.168.176.130.49890 > 192.168.176.20.http: . ack 1 win 46
<nop,nop,timestamp 241035 2028417>
21:05:01.583470 IP 192.168.176.130.49890 > 192.168.176.20.http: P 1:300(299) ack
1 win 46 <nop,nop,timestamp 241036 2028417>
21:05:01.583542 IP 192.168.176.20 > 192.168.176.130: ICMP host 192.168.176.20
unreachable - admin prohibited, length 359
21:05:01.787484 IP 192.168.176.130.49890 > 192.168.176.20.http: P 1:300(299) ack
1 win 46 <nop,nop,timestamp 241087 2028417>
21:05:01.787578 IP 192.168.176.20 > 192.168.176.130: ICMP host 192.168.176.20
unreachable - admin prohibited, length 359

It seems like the first few bytes are coming through but then the firewall is
blocking the connection.

Stopping the iptables firewall on 192.168.7.20 (the newly virtualized DomU)
makes the connection work again.

Taking a closer look at the iptables rules one can see the following in
/etc/sysconfig/iptables:

[...]
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
[...]
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
[...]
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Changing the rules to simply not use the state machine works and makes the
machine connectable again:
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 80 -j ACCEPT

NB: When connecting from another machine, which is not virtualized on the same
Dom0 the problem does not manifest itself. The same is true for the Dom0 as well.


Version-Release number of selected component (if applicable):
2.6.9-67.ELxenU on the DomU
2.6.18-59.el5bbHPmgmtxen on the Dom0 (internal koji build from bburns to fix the
32bit guest on 64bit host problem #250427)

How reproducible:
Always

Comment 1 Andreas Thienemann 2008-01-03 21:11:47 UTC
A bit further research shows this to be a somewhat known problem in general: 
http://lists.xensource.com/archives/html/xen-users/2007-04/msg00224.html and
http://lists.xensource.com/archives/html/xen-users/2007-04/msg00621.html and
http://lists.xensource.com/archives/html/xen-users/2007-04/msg00861.html have
some details.

Comment 2 Don Dutile (Red Hat) 2008-01-30 14:38:50 UTC
From further discussion on irc w/Andreas, this appears to be a duplicate of BZ
414131.   Once the patch for 414131 is built into a testable kernel, Andreas
will confirm the fix for this bz, and if it does fix the problem, then this bz
will be closed as a duplicate.
Also adding/tagging xen-maint for this bz.

Comment 3 Andreas Thienemann 2008-02-13 09:35:40 UTC
Seems to work fine. Applying
http://people.redhat.com/vgoyal/rhel4/RPMS.kernel/kernel-xenU-2.6.9-68.11.EL.i686.rpm
makes iptables state target work again.

Marking as a duplicate.

*** This bug has been marked as a duplicate of 414131 ***