Following advice from Stéphane on https://insights.ubuntu.com/2017/02/14/network-management-with-lxd-2-3/ we are trying to build a P2P VXLAN Unicast network connecting various LXD servers to establish an overlay network acessible by all containers. Is it possible to pass an option at creation time (or later) to activate encryption of the VXLANs? Seems to be possible with Docker, maybe with LXD as well?
We would prefer to use this rather that implement mesh VPN networks between hosts which will need to rely on a 3rd party solution (PeerVPN).
Also, it is not clear what are the advantages of using the openvswitch network driver compared with the native one, is anybody willing to explain the differences in features?
Thanks,
D.
PS: sorry if this is double-posted, I keep getting an error message after submission.
native vs openvswitch may give you a performance difference depending on kernel and workload. The other advantage of openvswitch is that it doesn’t appear to have a port limit on its bridges, so while a Linux bridge will fail after you bind 1024 containers, openvswitch won’t.
For encrypted vxlan, I’m not finding any good references on how this all works on Linux.
There are references to it being based on some kind of L2 IPSEC (MACSEC) but I can’t find how you’re supposed to tell the Linux kernel about keys.
If you have any reference on setting this up with iproute2 (the “ip” command), let me know and I’ll look into adding at least a basic version of this (probably simple PSK based encryption).
Hello Stéphane,
Thanks for the feedback. A quick look at Docker libnetwork seems that additional software is used in conjunction with iproute to provide “native” encryption.
Still, being able to stick to LXD with little reliance over extra utilities to manage networking would benefit the project, so feel free to add this to the lxc commands (or something similar to what Docker is using).
The first link appears to be for normal L3 IPSEC which isn’t quite what’s needed for VXLAN as it operates at the L2 layer and there’s nothing preventing containers from internally using a subnet or protocol which LXD isn’t aware of.
The second link (macsec) looks much better but it seems to assume that we know the remote host’s MAC which would effectively prevent its use with multicast VXLAN (and would require the remote MAC being set in config for unicast).
