Greetings! The attached patch adds support for having routed virtual networks, in addition to the masquerading setup possible with the "<forward />" stanza. I have added a <route dev="ethX" /> stanza (dev is optional), completely equivalent to the <forward /> stanza.

Summary of changes: * Added <route /> stanza to XML parsing/creation * Refactored qemudAddIptablesRules to allow for the routed network type * In iptables.c: * Renamed iptables(.*)ForwardAllowIn to iptables(.*)ForwardAllowRelatedIn, to better reflect their function * Added iptables(.*)ForwardAllowIn functions, that do not require traffic to be related Comments are very much appreciated :-)

søn, 09 03 2008 kl. 21:09 +0000, skrev Daniel P. Berrange: > On Sat, Mar 08, 2008 at 04:33:32PM +0100, Mads Chr. Olesen wrote: > > I have added a <route dev="ethX" /> stanza (dev is optional), completely > > equivalent to the <forward /> stanza. > > This is still forwarding of traffic, so I think we should just use the > existing <forward/> element and have an extra attribute to indiciate > the type of forwarding, eg > > <forward/> (defaults to mode="nat" for compat) > <forward mode="nat"/> > <forward mode="route"/> > <forward mode="nat" dev="ethX"/> > <forward mode="route" dev="ethX"/> Sure, makes sense - an updated patch is attached. > I'm a little unclear on how this actually works. You add iptables rules to > allow traffic in/out, but you're not adding any routing table entries, nor > turning on proxy_arp, so I don't see how this will actually work in practice. > > Are you assuming the admin has already added suitable routing rules & turned > on proxy arp ? Well, in my case (dedicated server, hetzner.de) this is all that is needed. My physical interface has IP 85.10.XXX.XXX, and then I have a secondary IP range which gets routed at that interface, IP range 78.47.YYY.YYY/30. I then setup my virtual interface with an IP in that range, by setting <ip address="78.47.YYY.YYY" netmask="255.255.255.248" /> Thus, to get packets routed at the virtual machines, it just needs to be allowed by iptables, and /proc/sys/net/ipv4/ip_forward needs to be set to 1. Other setups obviously might need more work.

On Mon, Mar 24, 2008 at 10:52:41AM +0100, Mads Chr. Olesen wrote: > Anything further I can do to help get this patch commited? > > I have been running with it, without problems across restarts, etc., for > a couple of weeks now. I still don't see where the routing rules are defined / take place with this setup. There must be rules somewhere specifying the routing for the subnet 78.47.YYY.YYY/30, but its not being done in your patchset AFAICT

In theory I think it might be possible to avoid the need to configure the local LAN router, by messing with proxy_arp, but I've not got it to work so far.