Re: [Openvpn-devel] OpenVPN in the Hypervisor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/05/12 15:50, Tom Kent wrote: >> But... I don't think that OpenVPN is the right approach as it is > not peer-to-peer solution. > > I agree that this is not the optimal solution, especially for > large/high bandwith setups. I was just looking for something that I > could get going with what I have today. My ideal setup would be a > central arbiter that hands out routing and encryption info each for > each p2p connection that is desired, but I don't know of anything > that does this currently. > >> If your hypervisor uses a tap interface, you can just have >> openvpn use > that tap interface "right away". > > I guess I need to read up a bit more on how tap interfaces work. I > guess I assumed that the hypervisor was controlling that, so there > wouldn't be room for openvpn to jump on it. But assuming it is as > you say, that seems very promising, and much easier to get going > than I though. Think of tap devices as a software based NIC, where a physical NIC would have the Ethernet cable a TAP device have a socket where you can read/write data from/to in an application instead. TAP devices are layer 2 capable, so it transports Ethernet frames between the TAP device and the application socket. TUN devices are almost the same, except they function on the IP layer, not the Ethernet layer. So instead of Ethernet frames, you get IP packets instead in the application. To use virtual devices in a bridge you need TAP devices, as bridges depends on Ethernet frames. > I think I'm going to try this out here in the next few days, and > see how easily I can get something setup. If I have luck I'll put > up a blog post about it. Cool! Thanks a lot! kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+pKXIACgkQDC186MBRfro5ZQCcDzKzbq84/f4zrI/UeJyLQcdR kAcAoK1agIgeyPrVinpQgXITa2fNYiVb =odIc -END PGP SIGNATURE-
Re: [Openvpn-devel] OpenVPN in the Hypervisor
> But... I don't think that OpenVPN is the right approach as it is not > peer-to-peer solution. I agree that this is not the optimal solution, especially for large/high bandwith setups. I was just looking for something that I could get going with what I have today. My ideal setup would be a central arbiter that hands out routing and encryption info each for each p2p connection that is desired, but I don't know of anything that does this currently. > If your hypervisor uses a tap interface, you can just have openvpn use that tap interface "right away". I guess I need to read up a bit more on how tap interfaces work. I guess I assumed that the hypervisor was controlling that, so there wouldn't be room for openvpn to jump on it. But assuming it is as you say, that seems very promising, and much easier to get going than I though. I think I'm going to try this out here in the next few days, and see how easily I can get something setup. If I have luck I'll put up a blog post about it. Thanks for the input, Tom
[Openvpn-devel] [PATCH] management: Don't require DAF_INITIAL_AUTH to send ADDRESS/DISCONNECT messages
From: Adrien Bustany
DAF_INITIAL_AUTH will only be set if a password was needed for client
authentication. This means that for password-less certificate
authentication, no DISCONNECT/ADDRESS messages would be sent.
---
src/openvpn/manage.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index 141..4148f7c 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -2474,7 +2474,7 @@ management_notify_client_close (struct management
*management,
struct man_def_auth_context *mdac,
const struct env_set *es)
{
- if ((mdac->flags & DAF_INITIAL_AUTH) && !(mdac->flags &
DAF_CONNECTION_CLOSED))
+ if (!(mdac->flags & DAF_CONNECTION_CLOSED))
{
msg (M_CLIENT, ">CLIENT:DISCONNECT,%lu", mdac->cid);
man_output_env (es, true, management->connection.env_filter_level,
"CLIENT");
@@ -2489,7 +2489,7 @@ management_learn_addr (struct management *management,
const bool primary)
{
struct gc_arena gc = gc_new ();
- if ((mdac->flags & DAF_INITIAL_AUTH) && !(mdac->flags &
DAF_CONNECTION_CLOSED))
+ if (!(mdac->flags & DAF_CONNECTION_CLOSED))
{
msg (M_CLIENT, ">CLIENT:ADDRESS,%lu,%s,%d",
mdac->cid,
--
1.7.8.1
[Openvpn-devel] [PATCH] Don't require DAF_INITIAL_AUTH to send ADDRESS/DISCONNECT messages
From: Adrien Bustany As discussed in [1], here is a cleaned up version of my patch to fix the sending of CLIENT:ADDRESS/CLIENT:DISCONNECT message on the management interface when using password-less TLS certificate authentication. It seems that DAF_INITIAL_AUTH is now unused, should I send another patch that removes it altogether? Adrien Bustany (1): management: Don't require DAF_INITIAL_AUTH to send ADDRESS/DISCONNECT messages src/openvpn/manage.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.8.1
Re: [Openvpn-devel] OpenVPN in the Hypervisor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/05/12 03:03, Tom Kent wrote: > I had an idea I wanted to run by people and see if its > feasiblehere goes. > > I've been hearing a lot about "virtualized" networking for VMs and > that got me thinking. It seems like OpenVPN would be a good tool > that could join a group of VMs into their own private LAN, > basically segregating them from the internet even though they're > just machines hosted by amazon, rackspace, or in my own server > room. This could all be done now by setting all the VMs up with the > openvpn client and getting them to connect, etc. The down side is > that this is a lot of configuration, and the machines would still > be exposed to the larger network. > > The idea I had, and wanted to run by, was if it would be possible > to integrate an openvpn client into the hypervisor's virtual > network card. This would make it so that from the moment the VM > boots up, it is only connected to the private LAN served by the > OpenVPN server. The VM would see just another NIC, but instead of > routing the data directly to the Hypervisor's NIC (tap) or NATing > it or whatever, it would go to an OpenVPN client library (that > wouldn't need a tun/tap device on the hypervisor) which sends the > data to the server over the udp connection. > > Is this something that would be technically feasible? Practically > feasible? I've only used the binaries before, is the client in a > state (is there a libopenvpn) where it could be plugged into > another program like QEMU/KVM? > See Gert's comment first, as I'm spinning a bit further on some of his ideas. The *nix platform has always tried to build a lot of small modules which does a restricted set of operations and make those modules do their job well. And then you combine these modules to do larger and more complex tasks. QEMU/KVM is two such modules (user-space qemu-kvm and the kvm kernel module). And OpenVPN is another such module which provides SSL VPN over a UDP or TCP socket. So in my perspective, it doesn't make sense to integrate OpenVPN codewise into QEMU/KVM. But if, say the libvirt daemon which takes care of managing the QEMU/KVM instances could be extended to kick off a OpenVPN process with the appropriate configuration options I think you'll see a more flexible and simpler integration all-in-all. libvirt can manage bridges for VMs. So you can setup many VMs, on one or more bridges. Then adding separate OpenVPN tap devices to each of these bridges will then give provide direct access to that "cluster" of VMs. So if libvirt could tackle kicking off OpenVPN with a specific and suitable config for each of the bridge networks it starts (where VPN is enabled, of course) ... then you should probably be able to get much closer. The reason for the bridging is to avoid complications for the VM if openvpn dies and pulls down the tap device. And using a bridge you can create a more elastic cluster with VMs. kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+o8eIACgkQDC186MBRfrrEAgCfa46sQ2I2YhYqouRnZMmYkt2N VvkAoJifmiPVJR3YuyqWNgWjnJndBSAg =/T75 -END PGP SIGNATURE-
Re: [Openvpn-devel] openssl ouch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/05/12 10:30, Samuli Seppänen wrote: > >> Jan Just Keijser wrote: >>> ouch: http://www.openssl.org/news/secadv_20120419.txt >>> >>> we need to investigate whether and how openvpn is affected. >>> >>> >> did somebody end up writing an 'authoritative' answer to the >> question if and how openvpn is affected by this bug? >> >> cheers, >> >> JJK >> > Hi all, > > Got a response from James: > > --- > > My reading on this is that OpenVPN is probably not vulnerable. > > Scanning the OpenVPN source for usage of the vulnerable methods > (d2i_*_bio or d2i_*_fp), I'm seeing several calls of the methods in > ssl.c, however the data passed to these methods is coming from > local sources. > > $ grep -Er '\bd2i_.*_(bio|fp)\b' . ./ssl.c: p12 = > d2i_PKCS12_bio(b64, NULL); ./ssl.c: p12 = > d2i_PKCS12_fp(fp, NULL); > > For example, above, we are passing the PKCS12 file to OpenSSL > methods that have been cited as vulnerable, however the PKCS12 file > is locally obtained so there's no capability for a malicious client > or server to try to push a malformed file to its peer as a part of > the OpenVPN or SSL/TLS protocols. > > Aside from this, the vulnerability text says that "In particular > the SSL/TLS code of OpenSSL is *not* affected." so the core SSL/TLS > implementation in OpenVPN should be immune. > > And in general, using the "tls-auth" option gives you another level > of protection against any OpenSSL issues that would involve a > direct attack on the SSL/TLS protocol. > > James I'm not sure which version James checked against, but those code paths shouldn't have changed much since the 2.1 release and to our latest master. And to confirm that: $ git grep -E '\bd2i_.*_(bio|fp)\b' src/openvpn/ssl_openssl.c: p12 = d2i_PKCS12_bio(b64, NULL); src/openvpn/ssl_openssl.c: p12 = d2i_PKCS12_fp(fp, NULL); Which identifies the same file. The ./ssl.c code got moved to ./ssl_openssl.c with Adriaan's PolarSSL implementation and further moved to src/openvpn/ssl_openssl.c with Alon's build clean-up. So I would say James' statement covers all 2.2, 2.3-alpha and up to the latest git master code. kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+o7oIACgkQDC186MBRfrrLtQCdHfXeKvGypSe4nMRTv5GbCjLs g1oAn34P/Zn6GE9ZVcmDT/zGlf77mrP3 =SWwd -END PGP SIGNATURE-
Re: [Openvpn-devel] openssl ouch
> Jan Just Keijser wrote: >> ouch: >> http://www.openssl.org/news/secadv_20120419.txt >> >> we need to investigate whether and how openvpn is affected. >> >> > did somebody end up writing an 'authoritative' answer to the question if > and how openvpn is affected by this bug? > > cheers, > > JJK > Hi all, Got a response from James: --- My reading on this is that OpenVPN is probably not vulnerable. Scanning the OpenVPN source for usage of the vulnerable methods (d2i_*_bio or d2i_*_fp), I'm seeing several calls of the methods in ssl.c, however the data passed to these methods is coming from local sources. $ grep -Er '\bd2i_.*_(bio|fp)\b' . ./ssl.c: p12 = d2i_PKCS12_bio(b64, NULL); ./ssl.c: p12 = d2i_PKCS12_fp(fp, NULL); For example, above, we are passing the PKCS12 file to OpenSSL methods that have been cited as vulnerable, however the PKCS12 file is locally obtained so there's no capability for a malicious client or server to try to push a malformed file to its peer as a part of the OpenVPN or SSL/TLS protocols. Aside from this, the vulnerability text says that "In particular the SSL/TLS code of OpenSSL is *not* affected." so the core SSL/TLS implementation in OpenVPN should be immune. And in general, using the "tls-auth" option gives you another level of protection against any OpenSSL issues that would involve a direct attack on the SSL/TLS protocol. James ---
Re: [Openvpn-devel] [RFC] Split plugins into their own repositories
> Hello David, > > On Mon, May 7, 2012 at 10:33 AM, David Sommerseth > wrote: > > > >> The reason I don't see the benefit of splitting out the plug-ins as >> much is that they all depend on OpenVPN. You can not make much use of >> these plug-ins without having OpenVPN. But with Windows TAP driver >> and easy-rsa, they can be completely used independently. >> >> Another point is that the plug-ins we have in the source tree, is >> officially supported plug-ins. And especially auth-pam and down-root >> are plug-ins which are very useful and we should encourage packagers >> to always package those. >> >> Then the example/ and defer/ plug-ins, which are examples. Maybe it >> would rather make sense to merge them somehow? > There are a lot of plugins out there, think about chrome extension or > firefox extension, but also network manager plugins or similar, they > are all depend on the core product, but extend its functionality, and > have their own repositories. > > Plugins should be installed as separate package, aka rpm. > > So if administrator wants openvpn he does: > # yum install openvpn > > Now, if administrator wants auth-pam, he should do: > # yum install openvpn-plugin-auth-pam > > As there is no sense in keeping the auth-pam plugin in system if it is > unused nor to have pam dependency of the openvpn core package. > > I would not encourage packages to always have them, it is also not the > correct approach for plugins. Plugins should be optional in nature. > > All the above does not imply separate repository as in both cases we > can either provide one .spec file that generate both rpms or two > separate spec files. > > The real question is how do we provide proper build for this > components. Currently it has poor-man-build, which I fixed to meet > some level of quality, instead of ./configure&&make install, packager > should go and figure own what else needs to be built in tree. > > So either these are officially supported and should be build properly > using main build system, example: > --- > $ ./configure --enable-plugin-auth-pam PAM_CFLAGS=... PAM_LIBS=... > --- > > Or have plugins as separate components with its own release cycle and > should have their proper own build system and release cycle. > > I think that if we have proper interface (openvpn-plugin.h), there is > no sense in providing the plugins within the tree, as it has its own > release cycle. > > I also would like to discuss the "official" argument > A project can have several repositories all at equal "official" level, > why on earth people think that having more than one repository around > damage their "official" state? "officially supported plug-ins", can be > official in the openvpn repository and can be official in their own > repository, there is absolutely no difference between the two > approaches in this regards. > > However, splitting the repositories, allow helping distro packaging in > determine what needed to be packaged and provided to users, it also > allow separate release cycle (new openvpn release does not force new > plugin release), and can even help in maintenance as a plugin can have > its own maintainer (commit access). > > If also has more advantage as now in github we can encourage people to > host and maintain their plugin within the OpenVPN organization, > attracting more skills. > So bottom line: > > 1. Either we add the plugins to core build system, with its disadvantages. > > 2. Split plugins into their own repository, release cycle, packaging. > > I am for (2), as I don't afraid of the "official" argument nor do I > afraid to commit to more than one repository, and the modular nature > of the plugin interface allows optional components to be installed > separately along with their own dependencies. > > Alon I think there's some very good argumentation here. In my view, separating plugins into their own repositories would have some important advantages; excuse me for repeating some of Alon's arguments here: 1) Delegating maintenance tasks easily to (new) developers: this is now trivial with GitHub 2) Avoid having to make an OpenVPN release due to an important fix in a plugin used by few. This also helps distro packagers, provided they didn't bundle the plugins in their core "openvpn" package Afaik none of the official plugins are needed to create the official Windows installers, so that platform is entirely unaffected. On *NIX side we only release source code. If we don't want to force people to fetch official plugin code using Git, providing tarballs would be trivial. I tend to agree that packagers should take care of packaging the plugins as they see fit and making sure they're compatible with their version of OpenVPN. For example, on Debian/Ubuntu the OpenVPN package includes "down-root" and "pam" plugins by default. However, I've never used those, and I know many others who don't either. Having the plugins in separate repositories would steer packagers to the (in my opinion) right di
Re: [Openvpn-devel] OpenVPN in the Hypervisor
Hi, On Mon, May 07, 2012 at 09:03:17PM -0400, Tom Kent wrote: > The idea I had, and wanted to run by, was if it would be possible to > integrate an openvpn client into the hypervisor's virtual network card. > This would make it so that from the moment the VM boots up, it is only > connected to the private LAN served by the OpenVPN server. The VM would see > just another NIC, but instead of routing the data directly to the > Hypervisor's NIC (tap) or NATing it or whatever, it would go to an OpenVPN > client library (that wouldn't need a tun/tap device on the hypervisor) > which sends the data to the server over the udp connection. If your hypervisor uses a tap interface, you can just have openvpn use that tap interface "right away". So don't bridge tap0 to eth0 on the Hypervisor, but just have tap0 available for the VMs, and run OpenVPN with "--dev tap0". This might be somewhat more expensive performance-wise - but it will be much cheaper programmer-time-wise, as all you need is already there and well-tested :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpqRN9nrhULg.pgp Description: PGP signature
Re: [Openvpn-devel] openssl ouch
> Jan Just Keijser wrote: >> ouch: >> http://www.openssl.org/news/secadv_20120419.txt >> >> we need to investigate whether and how openvpn is affected. >> >> > did somebody end up writing an 'authoritative' answer to the question if > and how openvpn is affected by this bug? > > cheers, > > JJK > Asked James to take a look at this. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
Re: [Openvpn-devel] OpenVPN in the Hypervisor
On Tue, May 8, 2012 at 4:03 AM, Tom Kent wrote: > I had an idea I wanted to run by people and see if its feasiblehere > goes. > > I've been hearing a lot about "virtualized" networking for VMs and that got > me thinking. It seems like OpenVPN would be a good tool that could join a > group of VMs into their own private LAN, basically segregating them from the > internet even though they're just machines hosted by amazon, rackspace, or > in my own server room. This could all be done now by setting all the VMs up > with the openvpn client and getting them to connect, etc. The down side is > that this is a lot of configuration, and the machines would still be exposed > to the larger network. > > The idea I had, and wanted to run by, was if it would be possible to > integrate an openvpn client into the hypervisor's virtual network card. This > would make it so that from the moment the VM boots up, it is only connected > to the private LAN served by the OpenVPN server. The VM would see just > another NIC, but instead of routing the data directly to the Hypervisor's > NIC (tap) or NATing it or whatever, it would go to an OpenVPN client library > (that wouldn't need a tun/tap device on the hypervisor) which sends the data > to the server over the udp connection. > > Is this something that would be technically feasible? Practically feasible? > I've only used the binaries before, is the client in a state (is there a > libopenvpn) where it could be plugged into another program like QEMU/KVM? > > Thanks for any input, > Tom Hello Tom, This is interesting of course. But... I don't think that OpenVPN is the right approach as it is not peer-to-peer solution. So I would not consider this a solution for the common users' requirement. Anyway, I think it is quite simple to setup this without any additional development. I use Gentoo, in my networking script all I need is to declare what I want. At this example I create vpn0, vm0, vm1 at same network (br0), similar configuration can create vpn1, vm2, vm3 at different network. All that is left to do is to run openvpn with vpn0 interface as a bridge, and optionally another daemon at vpn1 etc... --- # This is the vpn0 interface rc_need_vpn0="firewall" rc_provide_vpn0="!net" tuntap_vpn0="tap" iproute2_vpn0="group openvpn" config_vpn0="null" txqueuelen_vpn0="100" metric_vpn0="1" # this is vm0 interface tuntap_vm0="tap" iproute2_vm0="group kvm" config_vm0="null" # this is vm1 interface tuntap_vm1="tap" iproute2_vm1="group kvm" config_vm1="null" # bridge the all rc_provide_br0="!net" rc_need_br0="firewall net.vpn0 net.vm0 net.vm1" bridge_br0="vpn0 vm0 vm1" config_br0="null" brctl_br0="setfd 0 sethello 0 stp off" --- What do you think? Alon.
Re: [Openvpn-devel] openssl ouch
Jan Just Keijser wrote: ouch: http://www.openssl.org/news/secadv_20120419.txt we need to investigate whether and how openvpn is affected. did somebody end up writing an 'authoritative' answer to the question if and how openvpn is affected by this bug? cheers, JJK
Re: [Openvpn-devel] [PATCH] Signed-off-by: Jan Just Keijser
Hi Adriaan,
Adriaan de Jong wrote:
+void
+tls_ctx_load_ecdh_params (struct tls_root_ctx *ctx, const char
*curve_name
+)
+{
+#ifdef USE_SSL_EC
+ if (curve_name != NULL)
+ {
+int nid;
+EC_KEY *ecdh = NULL;
+
+nid = OBJ_sn2nid(curve_name);
+
+if (nid == 0)
+ msg(M_SSLERR, "unknown curve name (%s)", curve_name);
+else
+{
+ ecdh = EC_KEY_new_by_curve_name(nid);
+ if (ecdh == NULL)
+msg (M_SSLERR, "Unable to create curve (%s)", curve_name);
+ else
+ {
+const char *sname;
+
+if (!SSL_CTX_set_tmp_ecdh(ctx->ctx, ecdh))
+ msg (M_SSLERR, "SSL_CTX_set_tmp_ecdh: cannot add curve");
+
What is happening here exactly? Is the same key being reused for
every
connection, or is it magically regenerated by OpenSSL on every
connection?
the function SSL_CTX_set_tmp_ecdh is very similar to SSL_CTX_set_tmp
(for DH keys).
It adds the curve to the SSL CTX (ConTeXt); this CTX is used only when
negotiating the TLS channel - NOT the data channel. It is updated by
the OpenSSL TLS code automagically.
Thanks, I realise this is just about the control channel. Still: for a server setup, multiple control channels are set up (one for each connection).
What I'm reading here, but that could be a mistake is the following:
1. Determine Curve NID
2. Generate a new DH key based on the curve NID (ecdh =
EC_KEY_new_by_curve_name(nid);)
3. For the global context, set that key as the one be used.
Now, if that is correct, the same key is reused across multiple connections for a server setup.
Again, note that my assumptions here might be incorrect, especially in step 2.
Unfortunately, I can't find decent documentation for the OpenSSL functions.
What I'm mostly concerned with is the control channel setup. As I understand
it, there's two steps involved that can use elliptic curve crypto:
1. Authentication using ECDSA/RSA/DSA/whatever
2. Anonymous DH/ECDH negotiation to get a session key
What I'm wondering is, if you use ECDSA, how is the curve for ECDSA set? As I understand it, this patch only sets the ECDH curve and key, not the
The main reason for adding this patch is to allow the use of
certificates which are generated with ECDH keys and which are signed
with a SHA2 family hash; without this patch , this is not allowed.
That's what my question boils down to: isn't ECDSA, not ECDH the
certificate-based part of the algorithm? ECDH is anonymous, isn't it?
Finally one more comment: to be accepted into the main branch, this
needs manpage and command line documentation.
very true... but that applies to more patches ;)
Unfortunately true...
I hope that clarifies my concerns a little. Unfortunately, I haven't found a
good authoritative source for the functionality of SSL_CTX_set_tmp_ecdh. If it
works in a similar manner to SSL_CTX_set_tmp_rsa, then you would need to use
SSL_CTX_set_tmp_ecdh_callback instead to generate a new key for every control
channel (see the ssl_openssl.c code for an example of that).
Your questions are all very valid.
The documentation on these functions is indeed atrocious ... from what
I understood the SSL_CTX_set_tmp_ecdh function is very similar to the
SSL_CTX_set_tmp_dh function; there's also a 'set_tmp_dh_callback'
function which is not used very often, as the DH params are static for a
single server.
If you read the openssl code , file ssl/s3_lib.c and look for
SSL_CTRL_SET_TMP_ECDH then you'll find that the s3_lib.c code does treat
the calls pretty much the same - this leads me to believe that the
SSL_CTX_set_tmp_ecdh_callback function does NOT need to be used. To make
sure I will post a question to the openssl developers on this.
The main reason for adding this function to the openvpn server instance
is to ensure that enough 'ECDH entropy' , for lack of a better word, is
available so that SHA2 message signing is possible. Again, this is my
understanding of things, but I'm about as blind as you are when it comes
to understanding this part of the OpenSSL code base.
HTH,
JJK
[Openvpn-devel] OpenVPN in the Hypervisor
I had an idea I wanted to run by people and see if its feasiblehere goes. I've been hearing a lot about "virtualized" networking for VMs and that got me thinking. It seems like OpenVPN would be a good tool that could join a group of VMs into their own private LAN, basically segregating them from the internet even though they're just machines hosted by amazon, rackspace, or in my own server room. This could all be done now by setting all the VMs up with the openvpn client and getting them to connect, etc. The down side is that this is a lot of configuration, and the machines would still be exposed to the larger network. The idea I had, and wanted to run by, was if it would be possible to integrate an openvpn client into the hypervisor's virtual network card. This would make it so that from the moment the VM boots up, it is only connected to the private LAN served by the OpenVPN server. The VM would see just another NIC, but instead of routing the data directly to the Hypervisor's NIC (tap) or NATing it or whatever, it would go to an OpenVPN client library (that wouldn't need a tun/tap device on the hypervisor) which sends the data to the server over the udp connection. Is this something that would be technically feasible? Practically feasible? I've only used the binaries before, is the client in a state (is there a libopenvpn) where it could be plugged into another program like QEMU/KVM? Thanks for any input, Tom
