[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] One more NAT problem (not tranversing POSTROUTING)



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.