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

[Xen-devel] Problems with network-route/vif-route scripts



I've been attempting to get the network-route/vif-route scripts running
instead of using the traditional bridging setup, but running into some
puzzelling issues.

I changed the network-script & vif-script settings in xend-config.sxp to
the appropriate values. In the guest config I set an explicit IP address
as required for routing vif = [ 'mac=00:16:3e:1e:7c:a6, ip=10.13.4.222' ]
And inside the guest, configured eth0 with the matching IP address. This
all works fine - the host can connect to the guest, and vica-verca. 
Off-host communications to/from the guest are not getting any traffic.
I do have a regular Fedora iptables rulset loaded which denies all incoming
traffic except SSH, but the vif-route script adds a number of IPTables rules
which are supposed to deal with this, allowing all traffic to go straight
to the guest.

After a little debugging, I came across a couple of separate issues with
the vif-route script which all conspire to block off-host networking from
working as expected

 - The iptables rule is only added to the FORWARD rule - it also needs
   to be added to the INPUT rule, otherwise Dom0 firwall rules will hit
   DomU traffic too

 - The iptables rule is added to the end of the FORWARD rule, so if you
   have an existing catch all DENY/REJECT rule already, the Xen rule
   will never get matched

 - The rule is using '-m physdev --physdev-in $vif' to match guest traffic.
   The 'physdev' module rules, however, only match on interfaces which are
   part of a network bridge - obviously not the case for routed networking
   config, so even at the correct location in FORWARD they don't match

 - While the guest can transmit, it never receives anything back because
   the remote hosts can't do ARP lookups for the guest's IP address. The
   vif-route script turns on proxy_arp on the $vif, but the proxy_arp setting
   is also needed on the Dom0's public interface (eg eth0)

Based on this it would seem we need to change the current

 iptables -A FORWARD --source $ip -m physdev --physdev-in $vif -j ACCEPT

To instead do

 iptables -I INPUT --source $ip -i $vif -j ACCEPT
 iptables -I FORWARD --source $ip -i $vif -j ACCEPT

Since this stuff is dealt with in vif-common.sh it looks like we'll need to
remove that commonality between route & bridge scripts.

And add some logic to network-route which does

  dev=....discover primary public interface...
  sysctl -w net.ipv4.conf.$dev.proxy_arp = 1


I'm rather wondering if I've missed something incredibly stupid which would
avoid all these issues, but it certainly seems that the current vif-route 
scripts just won't work in their current state

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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