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

Re: [Xen-users] netfilter, conntrack, ip_nat_ftp problem

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] netfilter, conntrack, ip_nat_ftp problem
From: Vladislav Kurz <vladislav.kurz@xxxxxxxxxxx>
Date: Thu, 31 May 2007 18:30:55 +0200
Delivery-date: Thu, 31 May 2007 09:29:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200705300834.04726.a.wilms@xxxxxxxxxx>
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>
References: <200705281233.41427.vladislav.kurz@xxxxxxxxxxx> <200705300834.04726.a.wilms@xxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.5
On Wednesday 30 May 2007 08:34, Alexander Wilms wrote:
> Hi Vladislav,
>
> this all sounds familiar to me. Both problems seem to be related to the
> TCP/UDP Checksum problem. If you would look with wireshark into your
> packets you would see a lot of wrong checksums. And this explains both:
> Because of this the FTP nat helper doesn't rewrite the re-transmitted
> packets anymore and also confuses the rest of the connection tracking.
>
>
> Solution is quite simple. Switch of tx checksumming of your nic(s). E.g.
> "ethtool -K eth0 tx off"
> You have to find out which of your nics need it. In my setup I had to
> switch it off in dom0 and domU on all physical nics.
>
> HTH,
> Alex

Thanks a lot Alex,

I switched off checksum offloading on domU and FTP NAT helper started to work.
I still get some INVALID packets with FIN & RST flag set, and some bad tcp 
checksum in dom0 - domU traffic, so I will monitor it and perhaps switch off 
checksum on the real eth0 and xen-br0 (or the vifX) in dom0.

Anyway I think this must have affected quite a lot of xen users. TCP checksum 
offloading must break any statefull firewall in dom0, or do I miss something?
Why there is no note about this in docs? Or is our configuration so unusual? 
(dom0 as a firewall in front of domU guests) 

Thanks
        Vladislav Kurz


> On Montag 28 Mai 2007, Vladislav Kurz wrote:
> > Hello all,
> >
> > I have a problem with netfilter and connection tracking on Xen.
> >
> > My config is:
> > xen-3.0.3
> > linux-2.6.18
> > Debian Etch AMD64
> > 2x Xeon with Hyper-Threading enabled
> >
> > Network configuration in dom0 is like this:
> >
> > eth0, eth0:1, eth0:2,... (public IPs)
> > xenbr0 (private IPs)=vif1.x, vif2.x, vif3.x,...
> > I am not using netloop (vif0.x and veth0).
> >
> > I DNAT selected IPs/ports from public interface to different domU hosts
> > (one is webserver, other is mailserver, jabber server, FTP server, etc).
> > Connections from domU to internet a SNATed to one of public IPs.
> >
> > One problem is that ip_nat_ftp does not work. When someone connects with
> > passive FTP, and tries to open data connection, it connects to private
> > address. It seems like ip_nat_ftp is not working at all. (Active ftp is
> > OK).
> >
> > I have used Xen 2.0.4 with kernel 2.6.10 (i386) and ip_nat_ftp worked
> > fine.
> >
> >
> > Another problem I noticed is that connection tracking marks a lot of
> > packets as INVALID. (iptables -A INPUT -m state --state INVALID -j DROP)
> > These packets are often part of ESTABLISHED connections to servers in
> > domU, and somehow they are not DNATed and intead of getting into FORWARD
> > chain, they end up in INPUT. So instead of routing them to proper domU,
> > they hit dom0.
> >
> > I looks like the same problem I had on xen 2.0.4 with kernel 2.6.10 which
> > involved tcp window tracking and I got rid of it by setting sysctl
> > variables: net/ipv4/netfilter/ip_conntrack_tcp_be_liberal=1
> > net/ipv4/netfilter/ip_conntrack_log_invalid=1
> >
> > But in xen 3.0.3 with kernel 2.6.18 it does nothing. No logging, and
> > still a lot of INVALID packets.
> >
> > I spent whole day googling, and found only some loosely related problems
> > and no solution proposed for others worked for me. Does anyone know what
> > can be wrong with netfilter / conntrack?
> >
> > Moreover I found some vague note about possible deadlock if I use
> > bridging without netloop. Can someone shed more light on this?
> >
> > Thanks for all help
> > Regards
> >         Vladislav Kurz
> >
> > P.S. Thanks to xen developers for the good work.
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-users
>
> --
> ========================================
>
> ::: NEUE ANSCHRIFT AB  01. JUNI 2007 :::
> ::: Güterstr. 20 | D-42117 Wuppertal :::
>
> ========================================

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

<Prev in Thread] Current Thread [Next in Thread>