Unterschiede zwischen den Revisionen 5 und 6
Revision 5 vom 2007-09-18 11:30:49
Größe: 2708
Autor: lars
Kommentar: more links
Revision 6 vom 2007-09-18 17:38:55
Größe: 2752
Autor: lars
Kommentar: Kleinkram
Gelöschter Text ist auf diese Art markiert. Hinzugefügter Text ist auf diese Art markiert.
Zeile 3: Zeile 3:
The following short howto describes the setup of a xen installation with following properties: The following short howto describes the setup of a xen installation with the following properties:
Zeile 5: Zeile 5:
 * the domUs share a bridged network interface
Zeile 6: Zeile 7:
 * the domUs share a bridged network interface
Zeile 48: Zeile 48:
 * bridged firewall in domU: http://www.shorewall.net/XenMyWay.html
 * routed firewall in dom0: http://www.shorewall.net/XenMyWay-Routed.html
Zeile 51: Zeile 49:
 * bridged firewall in domU: http://www.shorewall.net/XenMyWay.html (hard to reproduce)
 * routed firewall in dom0: http://www.shorewall.net/XenMyWay-Routed.html (hard to reproduce)

TableOfContents

What is it about

The following short howto describes the setup of a xen installation with the following properties:

  • the host domU is isolated from the domUs
  • the domUs share a bridged network interface
  • a firewall in dom1 manages the traffic from domUs to the internet


What is the problem?

Maybe you would like to accomplish the previously described setup by using dom0 as the routing firewall?

It could look like the following:BR attachment:xen-network-not-working.png (dia source: attachment:xen-network-not-working.dia)

I tried hard to get this setup running, but a problem of iptables with the xen network bridge rendered this approach impossible.

What went wrong?

  • the traffic originating from the bridge xenbr0 should get forwared to eth in dom0

  • the problem: the masquerading iptables rules failed to change the source address of the packets - thus the packets had an invalid return path

Symptoms

  • pings from domUs reach the external router, but the source address is 10.0.1.x instead of 192.168.1.2 (as it should be)

Root cause

  • the packets are treated as IN=xenbr0 (which is ok) and OUT=xenbr0 (this should be eth0 instead)

  • despite this wrong attributes, the packets still get sent via eth0 (as they should)

  • even more mysterious: after adding a masqerading rule that would also match packets marked as OUT=xenbr0, the packets do not even reach eth0 anymore

Other reports

In the [http://www.shorewall.net/Xen.html shorewall howtos] you can find the following:

I know of no case where a user has successfully used NAT (including Masquerade) in a bridged Xen Dom0. So if you want to create a masquerading firewall/gateway using Xen, you need to do so in a DomU (see how I did it) or you must configure Xen to use routing  or NAT rather than the default bridging.


How it can be done

The following picture describes a setup that avoids the previously described problem, since there are no bridges configured in dom1.

attachment:xen-network-two-bridges.png (dia source: attachment:xen-network-two-bridges.dia)

The configuration details (xen and shorewall configuration files) will follow soon ...


Links

XenRoutingFirewall (zuletzt geändert am 2014-05-24 14:52:33 durch anonym)


Creative Commons Lizenzvertrag
This page is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.