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
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.
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.
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 ***