Bug 427443 - iptables state target breaks when running as DomU
iptables state target breaks when running as DomU
Status: CLOSED DUPLICATE of bug 414131
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Red Hat Kernel Manager
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2008-01-03 15:31 EST by Andreas Thienemann
Modified: 2008-02-13 04:35 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-13 04:35:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andreas Thienemann 2008-01-03 15:31:04 EST
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 > S
3974247404:3974247404(0) win 5840 <mss 1460,sackOK,timestamp 241035 0,nop,wscale 7>
21:05:01.579570 IP > S
757456538:757456538(0) ack 3974247405 win 5792 <mss 1460,sackOK,timestamp
2028417 241035,nop,wscale 2>
21:05:01.579620 IP > . ack 1 win 46
<nop,nop,timestamp 241035 2028417>
21:05:01.583470 IP > P 1:300(299) ack
1 win 46 <nop,nop,timestamp 241036 2028417>
21:05:01.583542 IP > ICMP host
unreachable - admin prohibited, length 359
21:05:01.787484 IP > P 1:300(299) ack
1 win 46 <nop,nop,timestamp 241087 2028417>
21:05:01.787578 IP > ICMP host
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 (the newly virtualized DomU)
makes the connection work again.

Taking a closer look at the iptables rules one can see the following in

-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:
Comment 1 Andreas Thienemann 2008-01-03 16:11:47 EST
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 2008-01-30 09:38:50 EST
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 04:35:40 EST
Seems to work fine. Applying
makes iptables state target work again.

Marking as a duplicate.

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

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