(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. e.g. DomU.1 has DHCP address of 10.0.0.50 (DHCP matches MAC to assign same address and simplifies in creating templates) DomU.2 has DHCP address of 10.0.0.60 (DHCP matches MAC to assign same address and simplifies in creating templates) etc. Dom0 eht0 has public IP of 92.82.72.100 that forwards port 22 + 80 + 443 to 10.0.0.50 Dom0 eht0 has public IP of 92.82.72.101 that forwards port 21 + 22 + 80 + 443 to 10.0.0.60 etc. 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 azherdev@yahoo.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Alexander, Am Dienstag, den 26.10.2010, 09:44 -0700 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. > > e.g. > > DomU.1 has DHCP address of 10.0.0.50 (DHCP matches MAC to assign same > address and simplifies in creating templates) > DomU.2 has DHCP address of 10.0.0.60 (DHCP matches MAC to assign same > address and simplifies in creating templates) > etc. > > Dom0 eht0 has public IP of 92.82.72.100 that forwards port 22 + 80 + > 443 to 10.0.0.50 > Dom0 eht0 has public IP of 92.82.72.101 that forwards port 21 + 22 + > 80 + 443 to 10.0.0.60 > etc. > > 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.So the terms your are searching are SNAT and DNAT. i would''t recommend pure Portforwarding, since it seems to much fiddling, which each individual port. Use SNAT and DNAT in Dom0 and protect your domU by simple Port-Filter...> > I also need to prevent a DomU from: a) stealing other IPsthis is simple: vif = [ ''ip=10.0.0.50,mac=AA:BB:CC:DD:EE:FF'' ]> and b) communicating with other private systems unless Dom0 sais ok.1) Each domU has its own Bridge or 2) 10.0.0.50/32 and only ONE Route to your GW aka Dom0> 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.No Need for openvSwitch - can be easily accomplished with simple Unix-Tools ;-)> > What do I need? I know how to accomplish most of it using real > hardware with firewalls, vlans, etc.Just ask aunt google for help, e.g. http://www.adamsinfo.com/full-nat-dnat-and-snat-aka-11-nat-1-to-1-nat/ seems sufficient for your needs.> > I am fairly new to Xen so please, if possible, provide examples. > > Alexander Zherdev > azherdev@yahoo.comhth, thomas> _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thank you Thomas,
Few followup questions:
1. Which network mode is best for this configuration? bridge, route, nat?
2. On my box, when I specified the IP in the vif section, it didn''t
prevent
anything nor did it assign that IP. I am booting into Windows 2003 and 2008
DomU.
The only way that I found that I can have Dom0 dictate the IP of the DomU was to
enable DHCP on the dnsmasq service in Dom0 and map the MAC to IP on it. Still
didn''t prevent the Windows user from assigning a static IP of their
choice and
being able to communicate between systems on the bridge and outside.
Is this a limitation of Windows or HVM or is something mis-configured on my end?
Here is my config of the W2K3 DomU:
import os, re
arch = os.uname()[4]
if re.search(''64'', arch):
arch_libdir = ''lib64''
else:
arch_libdir = ''lib''
kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 8192
name = "vm-app-1a"
uuid = "C37B45AE-62E3-4034-BAD6-D0D3E127333E"
vcpus = 2
pae = 1
acpi = 1
apic = 1
cpus = "2-7"
vif = [ ''type=ioemu, bridge=virbr0, mac=00:16:3e:00:01:02,
ip=192.168.122.150'' ]
disk = [ ''phy:/dev/vg00/vm-000002-0,hda,w'' ]
on_poweroff = ''destroy''
on_reboot = ''restart''
on_crash = ''restart''
device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
boot = "c"
sdl=0
vnc=1
vnclisten="10.20.30.40"
vncpasswd=''vncpass''
stdvga=0
serial=''pty''
usbdevice=''tablet''
Alexander Zherdev
azherdev@yahoo.com
________________________________
From: Thomas Halinka <lists@thohal.de>
To: Alexander Zherdev <azherdev@yahoo.com>
Cc: xen-users@lists.xensource.com
Sent: Tue, October 26, 2010 9:59:06 AM
Subject: Re: [Xen-users] Xen 3.4.2 networking help
Hi Alexander,
Am Dienstag, den 26.10.2010, 09:44 -0700 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.
>
> e.g.
>
> DomU.1 has DHCP address of 10.0.0.50 (DHCP matches MAC to assign same
> address and simplifies in creating templates)
> DomU.2 has DHCP address of 10.0.0.60 (DHCP matches MAC to assign same
> address and simplifies in creating templates)
> etc.
>
> Dom0 eht0 has public IP of 92.82.72.100 that forwards port 22 + 80 +
> 443 to 10.0.0.50
> Dom0 eht0 has public IP of 92.82.72.101 that forwards port 21 + 22 +
> 80 + 443 to 10.0.0.60
> etc.
>
> 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.
So the terms your are searching are SNAT and DNAT. i would''t recommend
pure Portforwarding, since it seems to much fiddling, which each
individual port.
Use SNAT and DNAT in Dom0 and protect your domU by simple Port-Filter...
>
> I also need to prevent a DomU from: a) stealing other IPs
this is simple:
vif = [ ''ip=10.0.0.50,mac=AA:BB:CC:DD:EE:FF'' ]
> and b) communicating with other private systems unless Dom0 sais ok.
1) Each domU has its own Bridge
or
2) 10.0.0.50/32 and only ONE Route to your GW aka Dom0
> 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.
No Need for openvSwitch - can be easily accomplished with simple
Unix-Tools ;-)
>
> What do I need? I know how to accomplish most of it using real
> hardware with firewalls, vlans, etc.
Just ask aunt google for help, e.g.
http://www.adamsinfo.com/full-nat-dnat-and-snat-aka-11-nat-1-to-1-nat/
seems sufficient for your needs.
>
> I am fairly new to Xen so please, if possible, provide examples.
>
> Alexander Zherdev
> azherdev@yahoo.com
hth,
thomas
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Pardon my long email below, I hope it will shed some light.
I''ve googled and tried various things but nothing seem to work. I have
upgraded
to 3.4.3 of Xen and the kernel had an update too.
My brain is fried right now. The only thing that seems to work is bridged mode.
In bridged mode, my DomU gets the DHCP from dnsmasq and it can then surf the
web. But I can''t get to it from outside. In route or nat mode, the DomU
can''t
even get out. Below is a test in NAT mode of xend.
Below I have a pretty verbose output of iptables, ip r, and ifconfig right after
I boot the physical server, then after I start the DomU, and then after I apply
the SNAT and DNAT settings (only ip r changes then).
I appreciate any help that you have.
-----------------------------
Kernel: 2.6.18-194.17.4.el5xen
Xen: 3.4.3
Source: www.gitco.de
/etc/xen/xend-config.sxp
(network-nat)
(vif-nat)
Attempted the SNAT/DNAT configuration using this:
iptables -t nat -A PREROUTING -i eth0 -d XXX.XXX.XXX.70 -j DNAT --to-destination
192.168.122.150
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.122.150 -j SNAT --to-source
XXX.XXX.XXX.70
route add -host XXX.XXX.XXX.70 vif1.0
arp -Ds XXX.XXX.XXX.70 vif1.0
-> SIOCSARP: Invalid argument
Windows Configuration
DHCP
IP 192.168.122.150
MS 255.255.255.0
GW 192.168.122.1
CLEAN BOOT ------------------------------------
ifconfig
eth0 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E
inet addr:XXX.XXX.XXX.67 Bcast:XXX.XXX.XXX.95
Mask:255.255.255.224
inet6 addr: fe80::225:90ff:fe1b:e67e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0:1 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E
inet addr:XXX.XXX.XXX.70 Bcast:XXX.XXX.XXX.95
Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
peth0 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E
inet6 addr: fe80::225:90ff:fe1b:e67e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:fafe0000-fb000000
virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 state
RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ip r
XXX.XXX.XXX.64/27 dev eth0 proto kernel scope link src XXX.XXX.XXX.67
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
169.254.0.0/16 dev eth0 scope link
default via XXX.XXX.XXX.65 dev eth0
/etc/dnsmasq.conf
dhcp-range=192.168.122.10,192.168.122.250,255.255.255.0,12h
dhcp-host=00:16:3e:00:01:02,192.168.122.150
/vm/cfg/vm-000002/vm-000002.xen
import os, re
arch = os.uname()[4]
if re.search(''64'', arch):
arch_libdir = ''lib64''
else:
arch_libdir = ''lib''
kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 8192
name = "vm-app-1a"
uuid = "C37B45AE-62E3-4034-BAD6-D0D3E127333E"
vcpus = 2
pae = 1
acpi = 1
apic = 1
cpus = "2-7"
vif = [ ''type=ioemu, bridge=virbr0, mac=00:16:3e:00:01:02,
ip=192.168.122.150'' ]
disk = [ ''phy:/dev/vg00/vm-000002-0,hda,w'' ]
on_poweroff = ''destroy''
on_reboot = ''restart''
on_crash = ''restart''
device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
boot = "c"
sdl=0
vnc=1
vnclisten="XXX.XXX.XXX.67"
vncpasswd=''vnc''
stdvga=0
serial=''pty''
usbdevice=''tablet''
AFTER VM CREATED ------------------------------------
ifconfig
eth0 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E
inet addr:XXX.XXX.XXX.67 Bcast:XXX.XXX.XXX.95
Mask:255.255.255.224
inet6 addr: fe80::225:90ff:fe1b:e67e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0:1 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E
inet addr:XXX.XXX.XXX.70 Bcast:XXX.XXX.XXX.95
Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
peth0 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E
inet6 addr: fe80::225:90ff:fe1b:e67e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Memory:fafe0000-fb000000
tap1.0 Link encap:Ethernet HWaddr 2E:59:30:A2:97:17
inet6 addr: fe80::2c59:30ff:fea2:9717/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
vif1.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet addr:192.168.122.21 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST MULTICAST MTU:1500 Metric:1
virbr0 Link encap:Ethernet HWaddr 2E:59:30:A2:97:17
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED PHYSDEV match --physdev-out vif1.0
ACCEPT udp -- anywhere anywhere PHYSDEV match
--physdev-in vif1.0 udp spt:bootpc dpt:bootps
ACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED PHYSDEV match --physdev-out vif1.0
ACCEPT all -- 192.168.122.150 anywhere PHYSDEV match
--physdev-in vif1.0
ACCEPT all -- anywhere 192.168.122.0/24 state
RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ip r
192.168.122.150 dev vif1.0 scope link src 192.168.122.21
XXX.XXX.XXX.64/27 dev eth0 proto kernel scope link src XXX.XXX.XXX.67
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
169.254.0.0/16 dev eth0 scope link
default via XXX.XXX.XXX.65 dev eth0
AFTER SNAT/DNAT -----------------------------
192.168.122.150 dev vif1.0 scope link src 192.168.122.21
XXX.XXX.XXX.70 dev vif1.0 scope link
XXX.XXX.XXX.64/27 dev eth0 proto kernel scope link src XXX.XXX.XXX.67
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
169.254.0.0/16 dev eth0 scope link
default via XXX.XXX.XXX.65 dev eth0
Alexander Zherdev
azherdev@yahoo.com
________________________________
From: Thomas Halinka <lists@thohal.de>
To: Alexander Zherdev <azherdev@yahoo.com>
Cc: xen-users@lists.xensource.com
Sent: Tue, October 26, 2010 9:59:06 AM
Subject: Re: [Xen-users] Xen 3.4.2 networking help
Hi Alexander,
Am Dienstag, den 26.10.2010, 09:44 -0700 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.
>
> e.g.
>
> DomU.1 has DHCP address of 10.0.0.50 (DHCP matches MAC to assign same
> address and simplifies in creating templates)
> DomU.2 has DHCP address of 10.0.0.60 (DHCP matches MAC to assign same
> address and simplifies in creating templates)
> etc.
>
> Dom0 eht0 has public IP of 92.82.72.100 that forwards port 22 + 80 +
> 443 to 10.0.0.50
> Dom0 eht0 has public IP of 92.82.72.101 that forwards port 21 + 22 +
> 80 + 443 to 10.0.0.60
> etc.
>
> 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.
So the terms your are searching are SNAT and DNAT. i would''t recommend
pure Portforwarding, since it seems to much fiddling, which each
individual port.
Use SNAT and DNAT in Dom0 and protect your domU by simple Port-Filter...
>
> I also need to prevent a DomU from: a) stealing other IPs
this is simple:
vif = [ ''ip=10.0.0.50,mac=AA:BB:CC:DD:EE:FF'' ]
> and b) communicating with other private systems unless Dom0 sais ok.
1) Each domU has its own Bridge
or
2) 10.0.0.50/32 and only ONE Route to your GW aka Dom0
> 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.
No Need for openvSwitch - can be easily accomplished with simple
Unix-Tools ;-)
>
> What do I need? I know how to accomplish most of it using real
> hardware with firewalls, vlans, etc.
Just ask aunt google for help, e.g.
http://www.adamsinfo.com/full-nat-dnat-and-snat-aka-11-nat-1-to-1-nat/
seems sufficient for your needs.
>
> I am fairly new to Xen so please, if possible, provide examples.
>
> Alexander Zherdev
> azherdev@yahoo.com
hth,
thomas
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Alexander Zherdev wrote:>Few followup questions: > >1. Which network mode is best for this configuration? bridge, route, nat?Personally, since you have a bunch of public IPs then I would suggest avoiding NAT. By definition, NAT == Broken and it causes all sorts of problems. If you configure your Dom0 with a bridge, then each DomU can use a public IP directly.>2. On my box, when I specified the IP in the vif section, it didn''t >prevent anything nor did it assign that IP. I am booting into >Windows 2003 and 2008 DomU.I''m not sure what, if anything, is done by setting an IP in the DomU config ! I vaguely recall that there is a mechanism for a PV guest to get this and use it when configuring the network. What you will need to do is configure iptables and/or ebtables (which I haven''t personally used) to limit what traffic is permitted from each DomU. Ideally you want to restrict traffic both by source IP address and by source MAC address - have you seen what happens when a device uses a MAC address that''s already in use ? The biggest issue with iptables and bridging is that you cannot restrict traffic which is outbound from the machine with the bridge (ie your Dom0) - you can restrict/control all inbound and forwarded traffic. Unfortunately, to do this will mean running iptables/ebtables scripts each time you start a guest and it''s new VIFs are configured. I''m not aware of any pre-existing scripts to do this. There is a third way, and that is to have a monitoring script that detects a machine using an address it''s not assigned - and to shut it down. Having your host shut down from under you is likely to get your attention and teach you not to do it again ! I''m not sure why you need to restrict IP traffic between guests. While it''s unlikely, one guest may have need of contact with another, just as it will almost certainly have need of contact with other hosts on the internet. Unless you are running an external firewall to protect them all (in which case the guest-guest traffic would be unprotected), there''s really no difference from them being separate hosts on the big bad internet and each should be configured with it''s own firewall. But really, apart from running a virtual network in Dom0, this is no different from a network with multiple physical machines - ie it''s a general networking problem rather than a Xen problem. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> I''m not sure what, if anything, is done by setting an IP in the DomU > config ! I vaguely recall that there is a mechanism for a PV guest to > get this and use it when configuring the network.Correct. For the most part, it does nothing of much importance> > What you will need to do is configure iptables and/or ebtables (which > I haven''t personally used) to limit what traffic is permitted from > each DomU. Ideally you want to restrict traffic both by source IP > address and by source MAC address - have you seen what happens when a > device uses a MAC address that''s already in use ? > The biggest issue with iptables and bridging is that you cannot > restrict traffic which is outbound from the machine with the bridge > (ie your Dom0) - you can restrict/control all inbound and forwarded > traffic.I''m not sure what you mean by this? On my Xen nodes, I have 2 NICs. NIC1 is connected to a public bridge (which has no IP assigned) which all the DomUs are connected to. I use ebtables and iptables to make sure that no traffic from NIC1 can get onto the INPUT chain of the Dom0. NIC2 is connected to a private bridge which my Dom0 has an ip assigned to it. I also have some private DomUs connected to this bridge.> Unfortunately, to do this will mean running iptables/ebtables scripts > each time you start a guest and it''s new VIFs are configured. I''m not > aware of any pre-existing scripts to do this.I have made scripts to do this on my setup. It''s very each. You have to create a new vif-bridge file for each DomU in /etc/xen/scripts (vif-bridge-x) and set the DomU config to use the respective file. Then in each vif-bridge-x file, comment out "handle_iptable" and call another script (iptables-up-x and iptables-down-x) which runs the correct iptables commands. You could also put the iptables calls directly in the vif-bridge-x file, however i keep them separate just to keep things neat. It also means I can call my iptables-up-x and iptables-down-x scripts without rebooting the DomU. I have also give each DomU an incoming chain and outgoing chain, meaning I can add rules easily which only apply to each DomU. I make heavy use of physdev.> > There is a third way, and that is to have a monitoring script that > detects a machine using an address it''s not assigned - and to shut it > down. Having your host shut down from under you is likely to get your > attention and teach you not to do it again ! > > > I''m not sure why you need to restrict IP traffic between guests. While > it''s unlikely, one guest may have need of contact with another, just > as it will almost certainly have need of contact with other hosts on > the internet. Unless you are running an external firewall to protect > them all (in which case the guest-guest traffic would be unprotected), > there''s really no difference from them being separate hosts on the big > bad internet and each should be configured with it''s own firewall.If you use my iptables scripts idea above, you can put rules in there to restrict inter-DomU communication. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Jonathan Tripathy wrote:>>The biggest issue with iptables and bridging is that you cannot >>restrict traffic which is outbound from the machine with the bridge >>(ie your Dom0) - you can restrict/control all inbound and forwarded >>traffic.>I''m not sure what you mean by this? On my Xen nodes, I have 2 NICs. >NIC1 is connected to a public bridge (which has no IP assigned) >which all the DomUs are connected to. I use ebtables and iptables to >make sure that no traffic from NIC1 can get onto the INPUT chain of >the Dom0. NIC2 is connected to a private bridge which my Dom0 has an >ip assigned to it. I also have some private DomUs connected to this >bridge.When a bridge is involved, there is a problem with physdev match (if I recall correctly) which means that outbound traffic on the firewall machine cannot be filtered because of the sequence in which the net stack does operations. The practical result is that you cannot apply rules filtering traffic which originates on the firewall and leaves via a bridge interface. I vaguely recall it''s to do with the matching/filtering happening before the outbound interface is determined - and that in turn is related to requirements for handling VPN traffic. You can still filter inbound traffic, and you can still forward transiting traffic - it''s only outbound traffic that originates on the firewall that is a problem. That is my understanding from following the Shorewall list for some time.>>Unfortunately, to do this will mean running iptables/ebtables >>scripts each time you start a guest and it''s new VIFs are >>configured. I''m not aware of any pre-existing scripts to do this. >I have made scripts to do this on my setup. It''s very each. You have >to create a new vif-bridge file for each DomU in /etc/xen/scripts >(vif-bridge-x) and set the DomU config to use the respective file. >Then in each vif-bridge-x file, comment out "handle_iptable" and >call another script (iptables-up-x and iptables-down-x) which runs >the correct iptables commands. You could also put the iptables calls >directly in the vif-bridge-x file, however i keep them separate just >to keep things neat. It also means I can call my iptables-up-x and >iptables-down-x scripts without rebooting the DomU. I have also give >each DomU an incoming chain and outgoing chain, meaning I can add >rules easily which only apply to each DomU. I make heavy use of >physdev.I don''t have a need for this myself at the moment. It might well be useful to others if you could upload examples to the Wiki - IIRC this question has come up several times in various forms. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
When a bridge is involved, there is a problem with physdev match (if I recall correctly) which means that outbound traffic on the firewall machine cannot be filtered because of the sequence in which the net stack does operations. The practical result is that you cannot apply rules filtering traffic which originates on the firewall and leaves via a bridge interface. I vaguely recall it''s to do with the matching/filtering happening before the outbound interface is determined - and that in turn is related to requirements for handling VPN traffic. You can still filter inbound traffic, and you can still forward transiting traffic - it''s only outbound traffic that originates on the firewall that is a problem. That is my understanding from following the Shorewall list for some time. ------------------------------------------------------------------------------------------------------------------------------------------ If you are refering to the OUTPUT chain of the Dom0 itself, surely you wouldn''t use physdev at all? Wouldn''t you just use "iptables -A OUTPUT -o ethx ...."? In any case, I don''t block by interface on the Dom0''s OUTPUT chain. No real need to when the INPUT chain is protected with "iptables -A INPUT -i ..." I only ever use physdev on the FORWARD chain, which works for both incoming and outgoing traffic. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Alexander, Am Dienstag, den 26.10.2010, 22:12 -0700 schrieb Alexander Zherdev:> Thank you Thomas, > > Few followup questions: > > 1. Which network mode is best for this configuration? bridge, route, > nat?bridged-setup> 2. On my box, when I specified the IP in the vif section, it didn''t > prevent anything nor did it assign that IP. I am booting into Windows > 2003 and 2008 DomU.Oh, you didnt say ur using HVM....> The only way that I found that I can have Dom0 dictate the IP of the > DomU was to enable DHCP on the dnsmasq service in Dom0 and map the MAC > to IP on it. Still didn''t prevent the Windows user from assigning a > static IP of their choice and being able to communicate between > systems on the bridge and outside.the ip-statement only works with pv-domains...> > Is this a limitation of Windows or HVM or is something mis-configured > on my end?hvm.> > Here is my config of the W2K3 DomU: > > > import os, re > arch = os.uname()[4] > if re.search(''64'', arch): > arch_libdir = ''lib64'' > else: > arch_libdir = ''lib'' > > kernel = "/usr/lib/xen/boot/hvmloader" > builder=''hvm'' > memory = 8192 > name = "vm-app-1a" > uuid = "C37B45AE-62E3-4034-BAD6-D0D3E127333E" > > vcpus = 2 > pae = 1 > acpi = 1 > apic = 1 > cpus = "2-7" > > vif = [ ''type=ioemu, bridge=virbr0, mac=00:16:3e:00:01:02, > ip=192.168.122.150'' ] > > disk = [ ''phy:/dev/vg00/vm-000002-0,hda,w'' ] > > on_poweroff = ''destroy'' > on_reboot = ''restart'' > on_crash = ''restart'' > > device_model = ''/usr/'' + arch_libdir + ''/xen/bin/qemu-dm'' > boot = "c" > > sdl=0 > vnc=1 > vnclisten="10.20.30.40" > vncpasswd=''vncpass'' > stdvga=0 > serial=''pty'' > usbdevice=''tablet'' > > > > > Alexander Zherdev > azherdev@yahoo.com > > > > > ______________________________________________________________________ > From: Thomas Halinka <lists@thohal.de> > To: Alexander Zherdev <azherdev@yahoo.com> > Cc: xen-users@lists.xensource.com > Sent: Tue, October 26, 2010 9:59:06 AM > Subject: Re: [Xen-users] Xen 3.4.2 networking help > > Hi Alexander, > > Am Dienstag, den 26.10.2010, 09:44 -0700 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. > > > > e.g. > > > > DomU.1 has DHCP address of 10.0.0.50 (DHCP matches MAC to assign > same > > address and simplifies in creating templates) > > DomU.2 has DHCP address of 10.0.0.60 (DHCP matches MAC to assign > same > > address and simplifies in creating templates) > > etc. > > > > Dom0 eht0 has public IP of 92.82.72.100 that forwards port 22 + 80 + > > 443 to 10.0.0.50 > > Dom0 eht0 has public IP of 92.82.72.101 that forwards port 21 + 22 + > > 80 + 443 to 10.0.0.60 > > etc. > > > > 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. > > So the terms your are searching are SNAT and DNAT. i would''t recommend > pure Portforwarding, since it seems to much fiddling, which each > individual port. > > Use SNAT and DNAT in Dom0 and protect your domU by simple > Port-Filter... > > > > > I also need to prevent a DomU from: a) stealing other IPs > > this is simple: > > vif = [ ''ip=10.0.0.50,mac=AA:BB:CC:DD:EE:FF'' ] > > > and b) communicating with other private systems unless Dom0 sais ok. > > 1) Each domU has its own Bridge > or > 2) 10.0.0.50/32 and only ONE Route to your GW aka Dom0 > > > 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. > > No Need for openvSwitch - can be easily accomplished with simple > Unix-Tools ;-) > > > > > What do I need? I know how to accomplish most of it using real > > hardware with firewalls, vlans, etc. > > Just ask aunt google for help, e.g. > http://www.adamsinfo.com/full-nat-dnat-and-snat-aka-11-nat-1-to-1-nat/ > > seems sufficient for your needs. > > > > > I am fairly new to Xen so please, if possible, provide examples. > > > > Alexander Zherdev > > azherdev@yahoo.com > > hth, > > > thomas > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Jonathan Tripathy wrote:>If you are refering to the OUTPUT chain of the Dom0 itself, surely >you wouldn''t use physdev at all? Wouldn''t you just use "iptables -A >OUTPUT -o ethx ...."?Dunno about iptables specifics - I only use Shorewall and I know it''s a limitation. But isn''t "-o ethx" a device match ? If there was a way around the limitation, I''m sure Tom Eastep would have figured it out.>In any case, I don''t block by interface on the Dom0''s OUTPUT chain. >No real need to when the INPUT chain is protected with "iptables -A >INPUT -i ..." >I only ever use physdev on the FORWARD chain, which works for both >incoming and outgoing traffic.Well for me input restrictions are sufficient on Dom0 since no-one else is running stuff on Dom0. On my DomUs I also block outbound by default so that "less security minded" users have less scope to cause problems and/or there is less scope if a machine gets compromised. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>If you are refering to the OUTPUT chain of the Dom0 itself, surely >you wouldn''t use physdev at all? Wouldn''t you just use "iptables -A >OUTPUT -o ethx ...."?Dunno about iptables specifics - I only use Shorewall and I know it''s a limitation. But isn''t "-o ethx" a device match ? If there was a way around the limitation, I''m sure Tom Eastep would have figured it out. ----------------------------------------------------------------------------------------------------- Hi Simon, Yes, "-o ethx" is indeed a device match, but it works differently to physdev, which really only works well on fordwarded traffic (Although I think it is supposed to work on all bridged traffic) Can you please post a link to information about this? I can''t find anything on Google about this. Thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Again, just a short step-by-step guide. Am Dienstag, den 26.10.2010, 23:54 -0700 schrieb Alexander Zherdev:> Pardon my long email below, I hope it will shed some light. > > I''ve googled and tried various things but nothing seem to work. I have > upgraded to 3.4.3 of Xen and the kernel had an update too.so u had a lot of fun ;-)> My brain is fried right now. The only thing that seems to work is > bridged mode. In bridged mode, my DomU gets the DHCP from dnsmasq and > it can then surf the web. But I can''t get to it from outside. In route > or nat mode, the DomU can''t even get out. Below is a test in NAT mode > of xend.Dont use NAT - its just MASQUERADING! Communication from internet would be only possible through portforwarding....> Below I have a pretty verbose output of iptables, ip r, and ifconfig > right after I boot the physical server, then after I start the DomU, > and then after I apply the SNAT and DNAT settings (only ip r changes > then). > > I appreciate any help that you have. > > ----------------------------- > > Kernel: 2.6.18-194.17.4.el5xen > Xen: 3.4.3 > Source: www.gitco.de > > /etc/xen/xend-config.sxp > (network-nat) > (vif-nat)Please do the following. - Disable default Firewall (only to get ur setup running) # service iptables off - Write down a ugly script, something like: #!/bin/bash # i used /27 since your public-net was /27 too # 192.168.128.65 is dom0-IP brctl addbr xen-privatelan ip a a 192.168.128.65/27 dev xen-privatelan ifconfig xen-privatelan up echo 1 > /proc/sys/net/ipv4/ip_forward - and save it e.g. to /etc/xen/scripts/network-mynet - make it executable chmod +x /etc/xen/scripts/network-mynet - change any kind of xen-networking-script to e.g. ... (network-script network-mynet) (vif-script vif-bridge) ..... ######## reboot ur dom0 ##################### After reboot setup your windows-box to use the bridge "xen-privatelan" - change domU.cfg ... vif = [ ''type=ioemu, bridge=xen-privatelan, mac=00:16:3e:00:01:02'' ] ..... - start ur domU - setup nw-settings in domU (192.168.128.70/27 gw: 192.168.128.65) ^^^^ dom0-IP - at this point u should be able to ping dom0 from ur domU! access to internet and from internet to domU should NOT work Otherwise triplecheck "brctl show", ip r s, and friends... - Setup "1:1-NAT" iptables -t nat -A PREROUTING -d XXX.XXX.XXX.70 -j DNAT --to-destination 192.168.128.70 iptables -t nat -A POSTROUTING -s 192.168.128.70 -j SNAT --to-source XXX.XXX.XXX.70 --> domU has internal IP 192.168.128.70 and is reachable via externalIP XXX.XXX.XXX.70 --> domU should be able to ping the "internet" --> domU should be available from "internet" trough XXX.XXX.XXX.70 Am i right? :-) cu, thomas> Attempted the SNAT/DNAT configuration using this: > > iptables -t nat -A PREROUTING -i eth0 -d XXX.XXX.XXX.70 -j DNAT > --to-destination 192.168.122.150 > iptables -t nat -A POSTROUTING -o eth0 -s 192.168.122.150 -j SNAT > --to-source XXX.XXX.XXX.70 > route add -host XXX.XXX.XXX.70 vif1.0 > arp -Ds XXX.XXX.XXX.70 vif1.0 > -> SIOCSARP: Invalid argument > > Windows Configuration > DHCP > IP 192.168.122.150 > MS 255.255.255.0 > GW 192.168.122.1 > > CLEAN BOOT ------------------------------------ > > ifconfig > eth0 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E > inet addr:XXX.XXX.XXX.67 Bcast:XXX.XXX.XXX.95 > Mask:255.255.255.224 > inet6 addr: fe80::225:90ff:fe1b:e67e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > eth0:1 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E > inet addr:XXX.XXX.XXX.70 Bcast:XXX.XXX.XXX.95 > Mask:255.255.255.224 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > > peth0 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E > inet6 addr: fe80::225:90ff:fe1b:e67e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Memory:fafe0000-fb000000 > > virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 > inet addr:192.168.122.1 Bcast:192.168.122.255 > Mask:255.255.255.0 > inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > > iptables -L > Chain INPUT (policy ACCEPT) > target prot opt source destination > ACCEPT udp -- anywhere anywhere udp > dpt:domain > ACCEPT tcp -- anywhere anywhere tcp > dpt:domain > ACCEPT udp -- anywhere anywhere udp > dpt:bootps > ACCEPT tcp -- anywhere anywhere tcp > dpt:bootps > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT all -- anywhere 192.168.122.0/24 state > RELATED,ESTABLISHED > ACCEPT all -- 192.168.122.0/24 anywhere > ACCEPT all -- anywhere anywhere > REJECT all -- anywhere anywhere > reject-with icmp-port-unreachable > REJECT all -- anywhere anywhere > reject-with icmp-port-unreachable > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > ip r > XXX.XXX.XXX.64/27 dev eth0 proto kernel scope link src > XXX.XXX.XXX.67 > 192.168.122.0/24 dev virbr0 proto kernel scope link src > 192.168.122.1 > 169.254.0.0/16 dev eth0 scope link > default via XXX.XXX.XXX.65 dev eth0 > > /etc/dnsmasq.conf > dhcp-range=192.168.122.10,192.168.122.250,255.255.255.0,12h > dhcp-host=00:16:3e:00:01:02,192.168.122.150 > > /vm/cfg/vm-000002/vm-000002.xen > import os, re > arch = os.uname()[4] > if re.search(''64'', arch): > arch_libdir = ''lib64'' > else: > arch_libdir = ''lib'' > > kernel = "/usr/lib/xen/boot/hvmloader" > builder=''hvm'' > memory = 8192 > name = "vm-app-1a" > uuid = "C37B45AE-62E3-4034-BAD6-D0D3E127333E" > > vcpus = 2 > pae = 1 > acpi = 1 > apic = 1 > cpus = "2-7" > vif = [ ''type=ioemu, bridge=virbr0, mac=00:16:3e:00:01:02, > ip=192.168.122.150'' ] > > disk = [ ''phy:/dev/vg00/vm-000002-0,hda,w'' ] > > on_poweroff = ''destroy'' > on_reboot = ''restart'' > on_crash = ''restart'' > > device_model = ''/usr/'' + arch_libdir + ''/xen/bin/qemu-dm'' > boot = "c" > > sdl=0 > vnc=1 > vnclisten="XXX.XXX.XXX.67" > vncpasswd=''vnc'' > stdvga=0 > serial=''pty'' > usbdevice=''tablet'' > > > > AFTER VM CREATED ------------------------------------ > > > > > ifconfig > eth0 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E > inet addr:XXX.XXX.XXX.67 Bcast:XXX.XXX.XXX.95 > Mask:255.255.255.224 > inet6 addr: fe80::225:90ff:fe1b:e67e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > eth0:1 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E > inet addr:XXX.XXX.XXX.70 Bcast:XXX.XXX.XXX.95 > Mask:255.255.255.224 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > > peth0 Link encap:Ethernet HWaddr 00:25:90:1B:E6:7E > inet6 addr: fe80::225:90ff:fe1b:e67e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Memory:fafe0000-fb000000 > > tap1.0 Link encap:Ethernet HWaddr 2E:59:30:A2:97:17 > inet6 addr: fe80::2c59:30ff:fea2:9717/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > vif1.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF > inet addr:192.168.122.21 Bcast:0.0.0.0 > Mask:255.255.255.255 > UP BROADCAST MULTICAST MTU:1500 Metric:1 > > virbr0 Link encap:Ethernet HWaddr 2E:59:30:A2:97:17 > inet addr:192.168.122.1 Bcast:192.168.122.255 > Mask:255.255.255.0 > inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > iptables -L > Chain INPUT (policy ACCEPT) > target prot opt source destination > ACCEPT udp -- anywhere anywhere udp > dpt:domain > ACCEPT tcp -- anywhere anywhere tcp > dpt:domain > ACCEPT udp -- anywhere anywhere udp > dpt:bootps > ACCEPT tcp -- anywhere anywhere tcp > dpt:bootps > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT all -- anywhere anywhere state > RELATED,ESTABLISHED PHYSDEV match --physdev-out vif1.0 > ACCEPT udp -- anywhere anywhere > PHYSDEV match --physdev-in vif1.0 udp spt:bootpc dpt:bootps > ACCEPT all -- anywhere anywhere state > RELATED,ESTABLISHED PHYSDEV match --physdev-out vif1.0 > ACCEPT all -- 192.168.122.150 anywhere > PHYSDEV match --physdev-in vif1.0 > ACCEPT all -- anywhere 192.168.122.0/24 state > RELATED,ESTABLISHED > ACCEPT all -- 192.168.122.0/24 anywhere > ACCEPT all -- anywhere anywhere > REJECT all -- anywhere anywhere > reject-with icmp-port-unreachable > REJECT all -- anywhere anywhere > reject-with icmp-port-unreachable > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > ip r > 192.168.122.150 dev vif1.0 scope link src 192.168.122.21 > XXX.XXX.XXX.64/27 dev eth0 proto kernel scope link src > XXX.XXX.XXX.67 > 192.168.122.0/24 dev virbr0 proto kernel scope link src > 192.168.122.1 > 169.254.0.0/16 dev eth0 scope link > default via XXX.XXX.XXX.65 dev eth0 > > > AFTER SNAT/DNAT ----------------------------- > > 192.168.122.150 dev vif1.0 scope link src 192.168.122.21 > XXX.XXX.XXX.70 dev vif1.0 scope link > XXX.XXX.XXX.64/27 dev eth0 proto kernel scope link src > XXX.XXX.XXX.67 > 192.168.122.0/24 dev virbr0 proto kernel scope link src > 192.168.122.1 > 169.254.0.0/16 dev eth0 scope link > default via XXX.XXX.XXX.65 dev eth0 > > > > > Alexander Zherdev > azherdev@yahoo.com > > > > > ______________________________________________________________________ > From: Thomas Halinka <lists@thohal.de> > To: Alexander Zherdev <azherdev@yahoo.com> > Cc: xen-users@lists.xensource.com > Sent: Tue, October 26, 2010 9:59:06 AM > Subject: Re: [Xen-users] Xen 3.4.2 networking help > > Hi Alexander, > > Am Dienstag, den 26.10.2010, 09:44 -0700 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. > > > > e.g. > > > > DomU.1 has DHCP address of 10.0.0.50 (DHCP matches MAC to assign > same > > address and simplifies in creating templates) > > DomU.2 has DHCP address of 10.0.0.60 (DHCP matches MAC to assign > same > > address and simplifies in creating templates) > > etc. > > > > Dom0 eht0 has public IP of 92.82.72.100 that forwards port 22 + 80 + > > 443 to 10.0.0.50 > > Dom0 eht0 has public IP of 92.82.72.101 that forwards port 21 + 22 + > > 80 + 443 to 10.0.0.60 > > etc. > > > > 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. > > So the terms your are searching are SNAT and DNAT. i would''t recommend > pure Portforwarding, since it seems to much fiddling, which each > individual port. > > Use SNAT and DNAT in Dom0 and protect your domU by simple > Port-Filter... > > > > > I also need to prevent a DomU from: a) stealing other IPs > > this is simple: > > vif = [ ''ip=10.0.0.50,mac=AA:BB:CC:DD:EE:FF'' ] > > > and b) communicating with other private systems unless Dom0 sais ok. > > 1) Each domU has its own Bridge > or > 2) 10.0.0.50/32 and only ONE Route to your GW aka Dom0 > > > 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. > > No Need for openvSwitch - can be easily accomplished with simple > Unix-Tools ;-) > > > > > What do I need? I know how to accomplish most of it using real > > hardware with firewalls, vlans, etc. > > Just ask aunt google for help, e.g. > http://www.adamsinfo.com/full-nat-dnat-and-snat-aka-11-nat-1-to-1-nat/ > > seems sufficient for your needs. > > > > > I am fairly new to Xen so please, if possible, provide examples. > > > > Alexander Zherdev > > azherdev@yahoo.com > > hth, > > > thomas > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Jonathan Tripathy wrote:>Yes, "-o ethx" is indeed a device match, but it works differently to >physdev, which really only works well on fordwarded traffic >(Although I think it is supposed to work on all bridged traffic)I''ll bow to your significantly greater knowledge in this area ! But the penny drops now, is ethx a real port or a bridge port ? I''ll hazzard a guess filtering output to the bridge interface (eg br0) would be handled differently to filtering output to a specific port on the bridge.> >Can you please post a link to information about this? I can''t find >anything on Google about this.This for starters : http://www.shorewall.net/bridge-Shorewall-perl.html>As described above, Shorewall bridge support requires the physdev >match feature of Netfilter/iptables. Physdev match allows rules to >be triggered based on the bridge port that a packet arrived on >and/or the bridge port that a packet will be sent over. The latter >has proved to be problematic because it requires that the evaluation >of rules be deferred until the destination bridge port is known. >This deferral has the unfortunate side effect that it makes IPSEC >Netfilter filtration incompatible with bridges. To work around this >problem, in kernel version 2.6.20 the Netfilter developers decided >to remove the deferred processing in two cases: > * When a packet being sent through a bridge entered the >firewall on another interface and was being forwarded to the bridge. > * When a packet originating on the firewall itself is >being sent through a bridge.Then I found this that suggests you need to use physdev http://bwachter.lart.info/linux/bridges.html And I even found one of my old posts : http://www.mail-archive.com/shorewall-users@lists.sourceforge.net/msg02967.html which references http://www.shorewall.net/pub/shorewall/4.0/shorewall-4.0.1/releasenotes.txt -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
:>Yes, "-o ethx" is indeed a device match, but it works differently to >physdev, which really only works well on fordwarded traffic >(Although I think it is supposed to work on all bridged traffic)I''ll bow to your significantly greater knowledge in this area ! But the penny drops now, is ethx a real port or a bridge port ? I''ll hazzard a guess filtering output to the bridge interface (eg br0) would be handled differently to filtering output to a specific port on the bridge.> >Can you please post a link to information about this? I can''t find >anything on Google about this.This for starters : http://www.shorewall.net/bridge-Shorewall-perl.html>As described above, Shorewall bridge support requires the physdev >match feature of Netfilter/iptables. Physdev match allows rules to >be triggered based on the bridge port that a packet arrived on >and/or the bridge port that a packet will be sent over. The latter >has proved to be problematic because it requires that the evaluation >of rules be deferred until the destination bridge port is known. >This deferral has the unfortunate side effect that it makes IPSEC >Netfilter filtration incompatible with bridges. To work around this >problem, in kernel version 2.6.20 the Netfilter developers decided >to remove the deferred processing in two cases: > * When a packet being sent through a bridge entered the >firewall on another interface and was being forwarded to the bridge. > * When a packet originating on the firewall itself is >being sent through a bridge.----------------------------------------------------------------------------------------------------------------------------------------------------------- Hmm that''s interesting. I guess my general rule of thumb is that I only ever use physdev--in and physdev--out for traffic which is on the FORWARD chain (specifically for DomU which have public IPs assigned to them). I''m a little confused about what "When a packet being sent through a bridge entered the firewall on another interface and was being forwarded to the bridge." means. Does that sentence mean that traffic destined for the INPUT chain of the firewall? I would agree that I don''t think using physdev to specify a specific bridge port works for the OUTPUT chain. In my example above, "-o ethx" would be e.g. br0. I guess that since my Dom0 is not used by untrusted parties, then I don''t have a need to filter by specific bridge (i.e. real) port. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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:
o 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.
o 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).
Regards,
Felix
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.
>
> e.g.
>
> DomU.1 has DHCP address of 10.0.0.50 (DHCP matches MAC to assign same
> address and simplifies in creating templates)
> DomU.2 has DHCP address of 10.0.0.60 (DHCP matches MAC to assign same
> address and simplifies in creating templates)
> etc.
>
> Dom0 eht0 has public IP of 92.82.72.100 that forwards port 22 + 80 +
> 443 to 10.0.0.50
> Dom0 eht0 has public IP of 92.82.72.101 that forwards port 21 + 22 +
> 80 + 443 to 10.0.0.60
> etc.
>
> 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
> *azherdev@yahoo.com <mailto:azherdev@yahoo.com>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Thomas,
Thank you for your explanation. Here is where I am right now.
I have the standard network bridge scripts fired off with xen:
network-bridge
vif-bridge
The DomU is DHCP and gets an ip of 192.168.122.150/24 with 192.168.122.1 as
GW+DNS from the dnsmasq service running on Dom0.
Dom0 has the following network (CentOS xen):
- 1.2.3.64/27 network
- 1.2.3.65 gateway
- 1.2.3.67 on eth0 which is what I use for Dom0 communication (ssh)
- 1.2.3.70 is the 2nd IP tied to eth0:1 of Dom0 that I want to use as direct
mapping to one of my DomU
DomU has the following network (Windows 2003 HVM):
- 192.168.122.0/24
- 192.168.122.1 gateway
- 192.168.122.150 IP
When I boot DomU I can:
- Ping from Dom0 to DomU 192.168.122.150
- Ping from DomU to Dom0 192.168.122.1 as well as www.google.com, 1.2.3.67,
etc.
- Surf the web on DomU
So the setup that you have suggested appears to work using the default xen
scripts.
I then ran the iptables commands that you suggested for the 1:1 NAT as follows:
iptables -t nat -A PREROUTING -d 1.2.3.70 -j DNAT --to-destination
192.168.122.150
iptables -t nat -A POSTROUTING -s 192.168.122.150 -j SNAT --to-source 1.2.3.70
But I can not access the system from outside. I did a tcpdump and I see the
1.2.3.70 being requested for the RDP port and it replies back as no port found.
No forwarding of any sort.
Could this be because my Dom0 and DomU have different subnets? My Dom0 is on /27
and my DomU reside on /24. I feel like I''m a command line away from
accomplishing this.
At the risk of being redundant, here is what I see with iptables and ip r s with
the above setup:
ifconfig:
eth0 - 1.2.3.67/27
eth0:1 - 1.2.3.70/27
peth0 - noip
tap1.0 - noip
vif1.0 - noip
virbr0 - 192.168.122.1/24
iptables:
------------------------
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 state
RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ip r s
----------------------
96.44.171.64/27 dev eth0 proto kernel scope link src 96.44.171.67
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
169.254.0.0/16 dev eth0 scope link
default via 96.44.171.65 dev eth0
Alexander Zherdev
azherdev@yahoo.com
________________________________
From: Thomas Halinka <lists@thohal.de>
To: Alexander Zherdev <azherdev@yahoo.com>
Cc: xen-users@lists.xensource.com
Sent: Wed, October 27, 2010 2:40:45 AM
Subject: Re: [Xen-users] Xen 3.4.2 networking help
Hi Again,
just a short step-by-step guide.
Am Dienstag, den 26.10.2010, 23:54 -0700 schrieb Alexander
Zherdev:> Pardon my long email below, I hope it will shed some light.
>
> I''ve googled and tried various things but nothing seem to work. I
have
> upgraded to 3.4.3 of Xen and the kernel had an update too.
so u had a lot of fun ;-)
> My brain is fried right now. The only thing that seems to work is
> bridged mode. In bridged mode, my DomU gets the DHCP from dnsmasq and
> it can then surf the web. But I can''t get to it from outside. In
route
> or nat mode, the DomU can''t even get out. Below is a test in NAT
mode
> of xend.
Dont use NAT - its just MASQUERADING! Communication from internet would
be only possible through portforwarding....
> Below I have a pretty verbose output of iptables, ip r, and ifconfig
> right after I boot the physical server, then after I start the DomU,
> and then after I apply the SNAT and DNAT settings (only ip r changes
> then).
>
> I appreciate any help that you have.
>
> -----------------------------
>
> Kernel: 2.6.18-194.17.4.el5xen
> Xen: 3.4.3
> Source: www.gitco.de
>
> /etc/xen/xend-config.sxp
> (network-nat)
> (vif-nat)
Please do the following.
- Disable default Firewall (only to get ur setup running)
# service iptables off
- Write down a ugly script, something like:
#!/bin/bash
# i used /27 since your public-net was /27 too
# 192.168.128.65 is dom0-IP
brctl addbr xen-privatelan
ip a a 192.168.128.65/27 dev xen-privatelan
ifconfig xen-privatelan up
echo 1 > /proc/sys/net/ipv4/ip_forward
- and save it e.g. to
/etc/xen/scripts/network-mynet
- make it executable
chmod +x /etc/xen/scripts/network-mynet
- change any kind of xen-networking-script to e.g.
...
(network-script network-mynet)
(vif-script vif-bridge)
.....
######## reboot ur dom0 #####################
After reboot setup your windows-box to use the bridge "xen-privatelan"
- change domU.cfg
...
vif = [ ''type=ioemu, bridge=xen-privatelan,
mac=00:16:3e:00:01:02'' ]
.....
- start ur domU
- setup nw-settings in domU (192.168.128.70/27 gw: 192.168.128.65)
^^^^ dom0-IP
- at this point u should be able to ping dom0 from ur domU!
access to internet and from internet to domU should NOT work
Otherwise triplecheck "brctl show", ip r s, and friends...
- Setup "1:1-NAT"
iptables -t nat -A PREROUTING -d XXX.XXX.XXX.70 -j DNAT
--to-destination 192.168.128.70
iptables -t nat -A POSTROUTING -s 192.168.128.70 -j SNAT --to-source
XXX.XXX.XXX.70
--> domU has internal IP 192.168.128.70 and is reachable via externalIP
XXX.XXX.XXX.70
--> domU should be able to ping the "internet"
--> domU should be available from "internet" trough XXX.XXX.XXX.70
Am i right? :-)
cu,
thomas
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Issue resolved! Simple issue, 4 days gone. :( Thank you all for your help!
Explanation below.
Kept everything stock in terms of xen bridge configuration. Using dnsmasq for
MAC to IP DHCP mapping (to keep DomU config simple).
Booted DomU
- DomU sees the internet, has 192.168.122.150 IP, /24 network, 192.168.122.1
GW and DNS
- Dom0 can ping DomU
- Internet can not see DomU on 1.2.3.70 IP
- Internet CAN ping 1.2.3.70, but it''s eth0 of Dom0
- Can''t RDP from public IP 1.2.3.70 to DomU Windows
Applied this:
iptables -t nat -A PREROUTING -i eth0 -d 1.2.3.70 -j DNAT --to-destination
192.168.122.150
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.122.150 -j SNAT --to-source
1.2.3.70
Pinging 1.2.3.70 from the internet is now unreachable
Removed rule 4 and 5 from the default forward policy in iptables
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 state
RELATED,ESTABLISHED
2 ACCEPT all -- 192.168.122.0/24 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with
icmp-port-unreachable
5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with
icmp-port-unreachable
Now I can ping AND rdp into my DomU from 1.2.3.70 public IP!
Current full iptables:
Table: nat
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
1 DNAT all -- 0.0.0.0/0 1.2.3.70 to:192.168.122.150
Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
1 MASQUERADE all -- 192.168.122.0/24 !192.168.122.0/24
2 SNAT all -- 192.168.122.150 0.0.0.0/0 to:1.2.3.70
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Table: filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
3 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 state
RELATED,ESTABLISHED
2 ACCEPT all -- 192.168.122.0/24 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Alexander Zherdev
azherdev@yahoo.com
________________________________
From: Alexander Zherdev <azherdev@yahoo.com>
To: lists@thohal.de; xen-users@lists.xensource.com
Sent: Wed, October 27, 2010 11:22:54 PM
Subject: Re: [Xen-users] Xen 3.4.2 networking help
Thomas,
Thank you for your explanation. Here is where I am right now.
I have the standard network bridge scripts fired off with xen:
network-bridge
vif-bridge
The DomU is DHCP and gets an ip of 192.168.122.150/24 with 192.168.122.1 as
GW+DNS from the dnsmasq service running on Dom0.
Dom0 has the following network (CentOS xen):
- 1.2.3.64/27 network
- 1.2.3.65 gateway
- 1.2.3.67 on eth0 which is what I use for Dom0 communication (ssh)
- 1.2.3.70 is the 2nd IP tied to eth0:1 of Dom0 that I want to use as direct
mapping to one of my DomU
DomU has the following network (Windows 2003 HVM):
- 192.168.122.0/24
- 192.168.122.1 gateway
- 192.168.122.150 IP
When I boot DomU I can:
- Ping from Dom0 to DomU 192.168.122.150
- Ping from DomU to Dom0 192.168.122.1 as well as www.google.com, 1.2.3.67,
etc.
- Surf the web on DomU
So the setup that you have suggested appears to work using the default xen
scripts.
I then ran the iptables commands that you suggested for the 1:1 NAT as follows:
iptables -t nat -A PREROUTING -d 1.2.3.70 -j DNAT --to-destination
192.168.122.150
iptables -t nat -A POSTROUTING -s 192.168.122.150 -j SNAT --to-source 1.2.3.70
But I can not access the system from outside. I did a tcpdump and I see the
1.2.3.70 being requested for the RDP port and it replies back as no port found.
No forwarding of any sort.
Could this be because my Dom0 and DomU have different subnets? My Dom0 is on
/27 and my DomU reside on /24. I feel like I''m a command line away from
accomplishing this.
At the risk of being redundant, here is what I see with iptables and ip r s with
the above setup:
ifconfig:
eth0 - 1.2.3.67/27
eth0:1 - 1.2.3.70/27
peth0 - noip
tap1.0 - noip
vif1.0 - noip
virbr0 - 192.168.122.1/24
iptables:
------------------------
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 state
RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with
icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ip r s
----------------------
96.44.171.64/27 dev eth0 proto kernel scope link src 96.44.171.67
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
169.254.0.0/16 dev eth0 scope link
default via 96.44.171.65 dev eth0
Alexander Zherdev
azherdev@yahoo.com
________________________________
From: Thomas Halinka <lists@thohal.de>
To: Alexander Zherdev <azherdev@yahoo.com>
Cc: xen-users@lists.xensource.com
Sent: Wed, October 27, 2010 2:40:45 AM
Subject: Re: [Xen-users] Xen 3.4.2 networking help
Hi Again,
just a short step-by-step guide.
Am Dienstag, den 26.10.2010, 23:54 -0700 schrieb Alexander
Zherdev:> Pardon my long email below, I hope it will shed some light.
>
> I''ve googled and tried various things but nothing seem to work. I
have
> upgraded to 3.4.3 of Xen and the kernel had an update too.
so u had a lot of fun ;-)
> My brain is fried right now. The only thing that seems to work is
> bridged mode. In bridged mode, my DomU gets the DHCP from dnsmasq and
> it can then surf the web. But I can''t get to it from outside. In
route
> or nat mode, the DomU can''t even get out. Below is a test in NAT
mode
> of xend.
Dont use NAT - its just MASQUERADING! Communication from internet would
be only possible through portforwarding....
> Below I have a pretty verbose output of iptables, ip r, and ifconfig
> right after I boot the physical server, then after I start the DomU,
> and then after I apply the SNAT and DNAT settings (only ip r changes
> then).
>
> I appreciate any help that you have.
>
> -----------------------------
>
> Kernel: 2.6.18-194.17.4.el5xen
> Xen: 3.4.3
> Source: www.gitco.de
>
> /etc/xen/xend-config.sxp
> (network-nat)
> (vif-nat)
Please do the following.
- Disable default Firewall (only to get ur setup running)
# service iptables off
- Write down a ugly script, something like:
#!/bin/bash
# i used /27 since your public-net was /27 too
# 192.168.128.65 is dom0-IP
brctl addbr xen-privatelan
ip a a 192.168.128.65/27 dev xen-privatelan
ifconfig xen-privatelan up
echo 1 > /proc/sys/net/ipv4/ip_forward
- and save it e.g. to
/etc/xen/scripts/network-mynet
- make it executable
chmod +x /etc/xen/scripts/network-mynet
- change any kind of xen-networking-script to e.g.
...
(network-script network-mynet)
(vif-script vif-bridge)
.....
######## reboot ur dom0 #####################
After reboot setup your windows-box to use the bridge "xen-privatelan"
- change domU.cfg
...
vif = [ ''type=ioemu, bridge=xen-privatelan,
mac=00:16:3e:00:01:02'' ]
.....
- start ur domU
- setup nw-settings in domU (192.168.128.70/27 gw: 192.168.128.65)
^^^^ dom0-IP
- at this point u should be able to ping dom0 from ur domU!
access to internet and from internet to domU should NOT work
Otherwise triplecheck "brctl show", ip r s, and friends...
- Setup "1:1-NAT"
iptables -t nat -A PREROUTING -d XXX.XXX.XXX.70 -j DNAT
--to-destination 192.168.128.70
iptables -t nat -A POSTROUTING -s 192.168.128.70 -j SNAT --to-source
XXX.XXX.XXX.70
--> domU has internal IP 192.168.128.70 and is reachable via externalIP
XXX.XXX.XXX.70
--> domU should be able to ping the "internet"
--> domU should be available from "internet" trough XXX.XXX.XXX.70
Am i right? :-)
cu,
thomas
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users