Re: [Qemu-devel] Win32 usermode only network possible?

[art yerkes <ayerkes@speakeasy.net>]

From: "John R. Hogerhuis" <jhoger@speakeasy.net>
Subject: Re: [Qemu-devel] Win32 usermode only network possible? [was: multiple VMs]
Date: Wed, 07 Apr 2004 15:04:28 -0700
Message-ID: <1081375468.14275.33.camel@aragorn>

jhoger> A SOCKS proxy would allow two way communication since it allows creation
jhoger> of listening sockets. But it requires configuration of the clients so
jhoger> it's not zero-install. Its other advantage is that it would not require
jhoger> priviledged access to the host. Most important networks apps are
jhoger> socksified and the setup is very easy (tell the app to use a certain
jhoger> socks server IP).

Although I'm new to this discussion, I'd like to share a few thoughts
I and another qemu user had earlier about networking in win32. 

Using SOCKS would still require each guest OS to provide some special 
mechanism for proxying SOCKS connections to the host OS.  Since that part
would be qemu specific, it's unlikely to my mind that such modifications
would be well received by the guest OS developers.  A userland server
is desirable, however, and so SOCKS is part of the model for what follow.

A while ago, I noticed a patch for bochs to put ethernet packets on normal
TCP connections, along with a little virtual hub to connect the bochses
together here:

http://cbothamy.free.fr/projects/bochs/patch.vhub  

Something quite similar, but a bit less fragile is the first part of what
I'd propose for qemu.  It's simple and flexible.  Since any type of program
can handle the bochs connections, making a hub is only the most trivial
thing that might be done, although that in itself is quite useful.

The second thing one would do is to write a smarter hub that did a few things:
- Listen for connections from qemus, and hear and relay their ethernet
  traffic.
- Listen on some user-configured ports to relay services provided by the
  guest to the outside, similar to what a firewall with NAT does when
  redirecting incoming traffic.  TCP SYN would be faked whenever a connection
  was ready to accept.
- The proxying program must eventually handle TCP, UDP and ICMP proxying.
  TCP will be the only difficult part, as the hub must compose fake ethernet
  traffic to send to the qemus, providing a sort of super SOCKS proxy.

The very nice thing about such as scheme is that it would allow the same
hubbing program to work with bochs as well as qemu, as well as allowing
more exotic proxy types to be developed independently from qemu.  Such
a scheme would also be trivial to interface to the likes of vtun and 
OpenVPN (which can run on windows).