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] One more NAT problem (not tranversing POSTROUTING)

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] One more NAT problem (not tranversing POSTROUTING)
From: Theo Cabrerizo Diem <diem@xxxxxxxxxxxx>
Date: Thu, 12 Oct 2006 15:32:37 +0200
Delivery-date: Thu, 12 Oct 2006 06:31:40 -0700
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
Hello there, aka: plleaasse help ;)

Idea :
All Xen VMs connects to xen-br bridge (which also dom0 is part of). If
they need access to outside (veth1 on dom0), dom0 does nat'ing.
The eth-br bridge is like a DMZ section, which I can plug my VMs which
provides services to outside world (but not in use yet)

Setup :
- Debian Linux unstable, xen unstable packages;
- one real ethernet card in the workstation; custom network scripts
- I don't rename any interface, so eth0 is the real one, veth* are the
virtual ones on dom0, which backs to vif0.*;
- module netloop nsloopback=2
- bridge eth-br, ports : eth0 vif0.0
- bridge xen-br, ports : vif0.1 + domU vif's

workstation setup is ok, I run dhclient on veth0, works perfectly
(default route goes through this interface), fixed ip on veth1 for
access to Xen VMs

Problem :
'iptables -t nat -A POSTROUTING -o veth0 -j MASQUERADE' doesn't work as
expected to NAT traffic from VMs :(

If I send a ping request to the outside world, I can see the icmp
request going through all interfaces, but completely unchanged (no nat
done). I saw earlier references in the archives to add a 'iptables -t
raw -A PREROUTING -i xen-br -j NOTRACK' to avoid connection tracking
when the packet is coming from vif3.0 to vif0.1 but this didn't help.

-- detailed part --
IP list :
dom0 veth0 -> 10.1.1.71
dom0 veth1 -> 192.168.235.1
dom0 default route via 10.1.1.254
domU eth0 -> 192.168.235.103
domU default route via 192.168.235.1

I've set LOG targets on iptables (dom0 of course), on every chain to see
which chains the packet is transversing and get a better ideia. this is
the result when sending a ping request from domU to 200.221.11.98 :


1: table RAW / PREROUTING   IN=xen-br OUT=
   PHYSIN=vif3.0
   SRC=192.168.235.1 DST=200.221.11.98
2: table NAT / PREROUTING   IN=xen-br OUT=
   PHYSIN=vif3.0
   SRC=192.168.235.1 DST=200.221.11.98
3: table FILTER / FORWARD   IN=xen-br OUT=xen-br
   PHYSIN=vif3.0 PHYSOUT=vif0.1
   SRC=192.168.235.1 DST=200.221.11.98
4: table NAT / POSTROUTING  IN=  OUT=xen-br
   PHYSIN=vif3.0 PHYSOUT=vif0.1
   SRC=192.168.235.1 DST=200.221.11.98
5: table FILTER / FORWARD   IN=veth1 OUT=veth0
   PHYSIN=vif3.0 PHYSOUT=vif0.1
   SRC=192.168.235.1 DST=200.221.11.98
6: table RAW / PREROUTING IN=eth-br OUT=
   PHYSIN=vif0.0
   SRC=192.168.235.1 DST=200.221.11.98
7: table FILTER / FORWARD   IN=eth-br OUT=eth-br
   PHYSIN=vif0.0 PHYSOUT=eth0
   SRC=192.168.235.1 DST=200.221.11.98

If I add the suggested NOTRACK stuff, the only difference is I don't see
lines 2 and 4.

I can see in the /proc/net/ip_conntrack the icmp entry in the conntrack
table, but no NAT occours :(

# cat /proc/net/ip_conntrack | grep icmp
icmp     1 25 src=192.168.235.103 dst=200.221.11.98 type=8 code=0
id=59140 packets=1 bytes=84 [UNREPLIED] src=200.221.1
1.98 dst=192.168.235.103 type=0 code=0 id=59140 packets=0 bytes=0 mark=0
use=1

my iptables setup :
* all policies ACCEPT
* -j LOG on every chain (with proper log-prefix to tell which is which)
* -t nat -A POSTROUTING -o veth0 -j MASQUERADE

Any idea ? :'(

Cheers,

Theo Diem


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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-users] One more NAT problem (not tranversing POSTROUTING), Theo Cabrerizo Diem <=