[ale] Virtual networks

[Dustin Strickland]

I've been meaning to follow up on this -- my "project" time is somewhat 
limited so any time I've made progress on this I've had to drop what I 
was doing to take care of more pressing matters... In any event, after 
making my own config that didn't work, I basically c+p'd yours, which 
also didn't work. After some poking around I found I had to set up NAT, 
and that was the last piece of the puzzle.

Thanks for your feedback everyone, and sorry for my misleading 
description -- I honestly wasn't aware that my "virtual network" wasn't 
a "virtual network". As an aside, I can understand the "virtual switch" 
model, but if it's all virtual, is it not a VLAN, or...?

On 5/12/2015 4:14 PM, Phil Turmel wrote:
> On 05/12/2015 03:01 PM, DJ-Pfulio wrote:
>> Network separation is smart. That may or may not use VLANs.
>>
>> Most cheap home networking gear doesn't support VLANs anyway.  A $20 GigE switch
>> on a different network provides better network segmentation than VLANs can. Just
>> need more cables and NIC ports, then setup the router with different subnets on
>> each port. Easy-peesy.
> I think y'all are talking past each other.  If I read Dustin's OP
> correctly, there's no VLAN here (in the 802.1q sense), just a virtual
> switch created by libvirtd.
>
> When you set up OpenVPN to allow users to reach your host machine, just
> push routing rules to the OpenVPN clients so they know to reach your
> virtual machines' private network via the tunnel.  You *do not* need to
> bridge your OpenVPN tunnel endpoint if you don't want to (I don't).  I
> use tunnel mode, actually, with very good results.  Some config snippets:
>
> ########### openvpn.conf on Public Router
> lport 1194
> dev tun
> proto tcp
> topology subnet
> keepalive 44 180
> float
> server 192.168.18.0 255.255.255.0
> route-gateway 192.168.18.1
> push "route-gateway dhcp"
> tun-mtu 1500
> push "tun-mtu 1500"
> ca    /etc/openvpn/XXX-ca.pem
> dh    /etc/openvpn/dh1024.pem
> cert  /etc/openvpn/XXX-server.pem
> key   /etc/openvpn/XXX-server.key
> persist-key
> persist-tun
> push "persist-tun"
> client-config-dir /etc/openvpn/XXX-server
> ccd-exclusive
> user openvpn
> group openvpn
> ifconfig-pool-persist /etc/openvpn/XXX-pool.txt
> push "route 192.168.16.0 255.255.240.0"
> client-to-client
>
> ########### openvpn.conf on road warriors
> remote router.example.com 1194
> proto tcp
> dev tun
> client
> verb 4
> auth-retry nointeract
> connect-timeout 60
> ca    /etc/openvpn/XXX-ca.pem
> cert  /etc/openvpn/XXX-client.pem
> key   /etc/openvpn/XXX-client.key
>
> #### Notes
> The CA is self-signed, with the private key kept offline.  The server
> and each client have certs signed by that CA.
>
> The road warriors all end up with an endpoint address in 192.168.18/24,
> with a route pointing down the tunnel for everything in 192.168.16/20.
> My office LAN and my VM virtual switches and some other subnets all have
> a /24 in that range.  The public facing router knows where they all are.
>   Omit the client-to-client option if none of yours are behind a client.
>
> Specific clients can have additional pushed configuration in their
> mandatory config files in the client config directory, keyed to their
> certificate common names.  Also an easy way to revoke permission for a
> given cert.
>
> Hope this helps,
>
> Phil
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo