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

Re: [Xen-users] Xen 3.4.2 networking help

Hi Jonathan,

I think a routed setup should suit your targets best, because you do not relay on LAN (i.e. Broadcasts, ARP) traffic between your DomUs if you are setting up a hosting server.

Actually I never used the default Xen scripts, because they seem to be rather broken / hard to use.

Some background:
  • Routing and Nat are actually no real different network scenario, NAT involves routing. The big difference is how the external ip addresses are handled:
    • NAT can be used to share one external ip address between multiple DomU's or to use the host's address for outbound traffic. You probably don't want that.
    • Pure routing requires a unique destination per ip address, i.e. the ip addresses that are used for the DomUs may only be used by a single DomU and they must *not* be used by the dom0 itself.
  • Setting up routing involves knowledge about: Routes, Subnets, ARP and Gateways. If you are unsure about any of these terms, you should do some research.
To start building up a routing script, all you need to do is:
  • A network script that enables ip forwarding in the kernel (the network-route script works fine in this way)
  • First start with a firewall-less test network to ensure the traffic is forwarded correctly (of course it must be a safe network, not already the Internet). Debugging routing problems gets lots harder when iptables is involved.
  • Write your own vif-script that basically does the following: Add the Dom0's gateway address (that will be configured as gateway in the DomU) to the vif and add a route to the DomU's ip address on that device. *Do not add* the DomU's address to the interface or to any other interface on the Dom0!
  • Use iproute2, i.e. /sbin/ip for everything; old utilities as ifconfig, route, etc work but are really pain (and do not supply all features).
If you got a working network configuration on the DomUs, you can start using iptables (iptables configuration gets easier if the setup is routed, because there is no bridge that forwards traffic by default. So traffic will only walk on your routes and you just have to accept everything that is sane, i.e. correct source ip / ethernet address, valid target, etc).


Am 26.10.2010 18:44, schrieb Alexander Zherdev:
(If this is a double post, I apologize, my email client crashed when I first sent it)

I need some help to configure a secure network on my Xen server. I have been looking online and it seems a I need a routed network. But I am having a terrible time implementing it.

My setup:

Xen 3.4.2
CentOS 5.5 Dom0
1 NIC (eth0)
 All guests will be HVM

What I want to do is something similar to a firewall and port forwarding.


DomU.1 has DHCP address of (DHCP matches MAC to assign same address and simplifies in creating templates)
DomU.2 has DHCP address of (DHCP matches MAC to assign same address and simplifies in creating templates)

Dom0 eht0 has public IP of that forwards port 22 + 80 + 443 to
Dom0 eht0 has public IP of that forwards port 21 + 22 + 80 + 443 to

Ideally, the main network card will have a bunch of public IPs that will individually route to internal DomU systems that have private IP addresses.

I also need to prevent a DomU from: a) stealing other IPs and b) communicating with other private systems unless Dom0 sais ok.
Right now, I do not need to have DomU on different physical servers sharing same network - what open vswitch provides as I understand it - that's phase 2. But of course if it provides what I need above easily, then I'm for it.

What do I need? I know how to accomplish most of it using real hardware with firewalls, vlans, etc.

I am fairly new to Xen so please, if possible, provide examples.
Alexander Zherdev
_______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
Xen-users mailing list



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