WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

[Xen-users] weird iptables problem with a RHEL4 xen guest

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] weird iptables problem with a RHEL4 xen guest
From: Jeroen Beerstra <jb@xxxxxxxxxxxxxxxxxx>
Date: Sun, 7 Jan 2007 03:12:35 +0100
Delivery-date: Sat, 06 Jan 2007 18:12:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.5
hi there,

I have this really weird problem with a RHEL4 (clone) xen guest. With the 
default firewall:

cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-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 21 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -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
COMMIT

I cannot connect to this guest from the host using ssh, although this should 
work as you can see above.

It looks like' -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j 
ACCEPT' is not matched for all packets from the host to the guest after the 
initial one, which makes the ssh client on the host wait forever. Also 
connecting to the host from the guest does not work, for example to the ftp 
server. The results are similar, there is an initial connection and after 
that nothing.

HOWEVER ssh from a server on my LAN to the guest works like expected, same for 
connections from the guest to the LAN, for example a local ftp server, works 
flawlessly :?

Looks to me (a xen novice) like there is something not alright with the xen 
bridge. I however don't have this problem with a FC6 guest running on the 
same system with the exact same firewall setup. The host is also FC6. It's a 
AMD64 box and both guests and host are x86_64.

For now I fixed this with:

-A RH-Firewall-1-INPUT -p tcp --dport 22 -j ACCEPT

But this ofcourse only fixes things for ssh, connecting to the host is still 
impossible :(

Anybody has any ideas what's going on or how to debug this further? Also let 
me know if I'm asking stuff in the wrong place.

Here's some info, let me know if you need more.

#xm info
host                   : neo.lokaal.net
release                : 2.6.18-1.2869.fc6xen
version                : #1 SMP Wed Dec 20 15:08:52 EST 2006
machine                : x86_64
nr_cpus                : 1
nr_nodes               : 1
sockets_per_node       : 1
cores_per_socket       : 1
threads_per_core       : 1
cpu_mhz                : 2009
hw_caps                : 078bfbff:e1d3fbff:00000000:00000010
total_memory           : 2047
free_memory            : 255
xen_major              : 3
xen_minor              : 0
xen_extra              : .3-0-1.2869.fc6
xen_caps               : xen-3.0-x86_64
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable 
cc_compiler            : gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)
cc_compile_by          : brewbuilder
cc_compile_domain      : build.redhat.com
cc_compile_date        : Wed Dec 20 14:48:14 EST 2006
xend_config_format     : 2

# cat VirtualXOS4
#  -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm 
create'.
# You use a separate script for each domain you want to create, or 
# you can set the parameters for the domain on the xm command line.
#============================================================================

#----------------------------------------------------------------------------
# Kernel image file.
#kernel = "/boot/vmlinuz-2.6.18-1.2869.fc6xen"
kernel = "/boot/vmlinuz-2.6.9-42.38.ELxenU"

# Optional ramdisk.
#ramdisk = "/boot/initrd-2.6.18-1.2869.fc6xenU.img"
ramdisk = "/boot/initrd-2.6.9-42.38.ELxenU.img"

# The domain build function. Default is 'linux'.
#builder='linux'

# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
#          memory errors. The domain needs enough memory to boot kernel
#          and modules. Allocating less than 32MBs is not recommended.
memory = 256

# A name for your domain. All domains must have different names.
name = "VirtualXOS4"

# 128-bit UUID for the domain.  The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"

# List of which CPUS this domain is allowed to use, default Xen picks
#cpus = ""         # leave to Xen to pick
#cpus = "0"        # all vcpus run on CPU0
#cpus = "0-3,5,^1" # run on cpus 0,2,3,5

# Number of Virtual CPUS to use, default is 1
#vcpus = 1

#----------------------------------------------------------------------------
# Define network interfaces.

# By default, no network interfaces are configured.  You may have one created
# with sensible defaults using an empty vif clause:
#
# vif = [ '' ]
#
# or optionally override backend, bridge, ip, mac, script, type, or vifname:
#
#vif = [ 'mac=00:16:3e:00:00:11, bridge=xenbr0' ]
#
# or more than one interface may be configured:
#
# vif = [ '', 'bridge=xenbr1' ]

vif = [ 'mac=00:16:3e:7c:f5:8a, bridge=xenbr0', ]

#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.

disk = [ 'file:/media/_data1/xen/xos4.img,hda,w' ]

#----------------------------------------------------------------------------
# Define to which TPM instance the user domain should communicate.
# The vtpm entry is of the form 'instance=INSTANCE,backend=DOM'
# where INSTANCE indicates the instance number of the TPM the VM
# should be talking to and DOM provides the domain where the backend
# is located.
# Note that no two virtual machines should try to connect to the same
# TPM instance. The handling of all TPM instances does require
# some management effort in so far that VM configration files (and thus
# a VM) should be associated with a TPM instance throughout the lifetime
# of the VM / VM configuration file. The instance number must be
# greater or equal to 1.
#vtpm = [ 'instance=1,backend=0' ]

#set vnc
vnc=1
#vncunused=1
#sdl=0

#----------------------------------------------------------------------------
# Set the kernel command line for the new domain.
# You only need to define the IP parameters and hostname if the domain's
# IP config doesn't, e.g. in ifcfg-eth0 or via DHCP.
# You can use 'extra' to set the runlevel and custom environment
# variables used by custom rc scripts (e.g. VMID=, usr= ).

# Set if you want dhcp to allocate the IP address.
#dhcp="dhcp"
# Set netmask.
#netmask=
# Set default gateway.
#gateway=
# Set the hostname.
#hostname= "vm%d" % vmid

# Set root device.
root = "/dev/VolGroup00/LogVol00 ro"

# Root device for nfs.
#root = "/dev/nfs"
# The nfs server.
#nfs_server = '169.254.1.0'  
# Root directory on the nfs server.
#nfs_root   = '/full/path/to/root/directory'

# Sets runlevel 4.
extra = "debug"

#----------------------------------------------------------------------------
# Configure the behaviour when a domain exits.  There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash.  For each of these you
# may specify:
#
#   "destroy",        meaning that the domain is cleaned up as normal;
#   "restart",        meaning that a new domain is started in place of the old
#                     one;
#   "preserve",       meaning that no clean-up is done until the domain is
#                     manually destroyed (using xm destroy, for example); or
#   "rename-restart", meaning that the old domain is not cleaned up, but is
#                     renamed and a new domain started in its place.
#
# The default is
#
#   on_poweroff = 'destroy'
#   on_reboot   = 'restart'
#   on_crash    = 'restart'
#
# For backwards compatibility we also support the deprecated option restart
#
# restart = 'onreboot' means on_poweroff = 'destroy'
#                            on_reboot   = 'restart'
#                            on_crash    = 'destroy'
#
# restart = 'always'   means on_poweroff = 'restart'
#                            on_reboot   = 'restart'
#                            on_crash    = 'restart'
#
# restart = 'never'    means on_poweroff = 'destroy'
#                            on_reboot   = 'destroy'
#                            on_crash    = 'destroy'

#on_poweroff = 'destroy'
#on_reboot   = 'restart'
#on_crash    = 'restart'

#============================================================================

# cat VirtualFC6
# Automatically generated xen config file
name = "VirtualFC6"
memory = "512"
disk = [ 'tap:aio:/media/_data1/xen/fc6.img,xvda,w', ]
vif = [ 'mac=00:16:3e:7c:f5:6a, bridge=xenbr0', ]
vnc=1
vncunused=1
uuid = "13a8aaed-e69e-d0df-d3b0-d539d35b6a1b"
bootloader="/usr/bin/pygrub"
vcpus=1
on_reboot   = 'restart'
on_crash    = 'restart'

-- 
regards,

Jeroen Beerstra

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-users] weird iptables problem with a RHEL4 xen guest, Jeroen Beerstra <=