Norbert Ehart ne at sil.at
Wed Jul 27 20:24:08 UTC 2005

On Wed, 27 Jul 2005, Eric S. Johansson wrote:

> Cybe R. Wizard wrote:
> > Thanks for the BIOS tip.
> >
> > I would certainly be interested in any information you may be willing to
> > share.  My email is as it appears in this post.
> might as well embarrass myself in front of the entire world.  Won't be
> the first time.  what I sent to the qemu folks.  I got the USENET nod so
> it must be correct.  ;-)
> ------------
> I have been stymied by the networking of qemu and I really want to try
> and solve my problems and hopefully document them so the solution is
> useful to others.
> Almost all the documentation I've seen so far makes the assumption
> that the end-user is network engineer level knowledgeable.  While this
> is an understandable focus, it does not help the user who sees QEMU as
> a tool to get a job done.  Approaching the narrative from a task
> oriented perspective may help QEMU be more accessible and reduce the
> support load.
> -----
> Some of the partially formed requirements going through the users mind
> might be:
> I want the guest OS to be able to access machines on the local LAN
> I want the guest OS to be able to access the Internet
> I want machines on the local LAN to access the guest OS
> I want machines on the Internet to access the guest OS
> A related thought which is an attempt to find a solution to all of the
> above is "I want the guest OS to have an address on the local LAN
> the four basic requirements can be collapsed into two (one inbound,
> one outbound) but the explanation must show how the two requirements
> are equivalent to the four basic requirements.
> as I understand the basic tun configuration, the network configuration
> looks something like the graphic below.
>                     +--------+
>                     |  host  |
>                  ======      |
>     LAN +-------+ eth0       |         +--------+
>                  ======      |         |  guest |
>                     |     ====== vlan ====      |
>                     |      tun0 +----+eth0      |
>                     |     ======      ====      |
>                     |        |         |        |
>                     +--------+         +--------+
> in this configuration the lan and the vlan are different subnets.
> (Note to network beginners, don't question, don't change, just accept
> this.)
> In achieving the outbound requirement, the guest OS uses the tun0
> interface as its gateway to the outside world.  Packets from the guest
> OS eth0 are routed through the tun0 interface then traverse the host
> and are delivered to the LAN via the host eth0.  If the packets are
> going further, than they are handed off to the gateway device for
> delivery
> Satisfying inbound requirement requires some vehicle for routing
> packets on the LAN to the VLAN subnet.  The most convenient place is
> the LAN gateway device (e.g. router, firewall etc.).  but if it's only
> necessary to enable a single external host, one can add the a point to
> point route on both the lan machine and the host machine.
> (note: while this basic outline works fine with Linux, for some
> reason connections initiated from windows don't work.)
> implementation example:
> Fill in these values (suggested values between parenthesis):
> IP address on host machine:
> Network definition for virtual LAN
> Subnet:  (
> netmask: (
> host tun address (
> guest address (
> network definition for host
> public host address:
> with all of these values defined, it's possible to start building a
> working configuration.  First, look at the default qemu ifup script:
> #!/bin/sh
> sudo -p "Password for $0:" /sbin/ifconfig $1
> as you can see, it's very simple but it's not complete if you want the
> guest machine accessible from the outside world.  When the script runs
> it creates tun0 with the host tun address.  As you can see, the
> default script uses the default value  if you are using a
> different value as document above, change the script to reflect that
> new value now.
> The reason I say it's not complete is that if you are trying to pass
> packets from eth0 to tun0, the default settings of most Linux
> distributions don't allow for packet forwarding.  The reason for this
> is security so that your host can't relate traffic for others.
> One should have IP tables entries to block any traffic except what is
> passing between the eth0 and tun0 interfaces but... (I've been
> wrestling with this problem on and off for a couple of days.  And as
> much as it has been fun, it doesn't put food on the table.  I need
> to get on with what I get paid for.  if someone wants to volunteer
> rules, I'll fit them into this document)
> in order to enable forwarding, add this line to the end of the default
> qemu_ifup script.  Because it does increase the risk to your machine
> and network, only do this if and when you want the qemu guest OS
> accessible from the outside world.:
>    echo 1 > /proc/sys/net/ipv4/ip_forward
> but once you do this, don't expose your machine to hostile networks.
> If you wish to eliminate this capability, simply type:
>   echo 0 > /proc/sys/net/ipv4/ip_forward
> and the forwarding feature will turn off isolating your guest machine
> from the network.
> Following the installation instruction's documented elsewhere, install
> your distribution of Linux or Windows and when it comes time to set up
> a network interface, use the guest address and virtual network netmask
> for the ethernet interface.  The gateway address for the guest OS will
> be the tun address
> Once the guest OS is running, see if the interfaces are reachable from
> the host machine.  Use ping to see of the tun and guest interfaces are
> alive.  Don't even think of trying this from an external machine.  It
> just won't work.
> the next stage is changing routing to make it possible to access the
> virtual network.  There are a couple ways to do this but I'm only
> going to cover the systemwide version.  Go to your gateway router.
> This is typically the box that connects you to the Internet.  If you
> do not have permission to modify this box, find someone who can or
> work solely on the host machine.
> what we want to do is route the guest network to the IP address of the
> host machine.  Using our sample data from above:
> route gateway
> a real example under Linux is:
> route add -net netmask gw
> from the router box, you should be able to ping the tun and guest
> addresses.  additional tests you may want to perform are ssh into and
> out of the guest machine as well as the usual http services.  One
> caution, I have found with this configuration that Linux machines can
> access the guest without problem but for some reason Windows machines
> don't work very well.
> If you have any problems, check routing, use TCP dump to verify that
> packets get to where they're supposed to go and that there are return
> packets coming back.  Most common failure is IP forwarding and
> improper gateway address set ups on the guest machine.  At least,
> those of the mistakes I made most often.
> --
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-users

More information about the ubuntu-users mailing list