A bit of good news about this: our containers created on Azure do can talk to our enterprise network and the Internet! (I haven’t played yet on how to make them accessible from our enterprise, tough.)
What I did (in a nutshell):
- Followed LXDoNe’s configuration guide to the line.
=> With two exceptions:
* I did not removed “eth0” from LXD’s profile.
* I run “lxd init” interactively, to make sure NAT would be enabled.
- After running “lxd init”, I collected the information regarding the internal network LXD automatically created for the containers.
- On OpenNebula, created a bridged Virtual Network with LXD’s network information and set “lxdbr0” as the bridge interface.
- Something important/unique tough: our enterprise has a VPN to Azure. The LXD host/node’s IP address is in that VPN.
- In this case, NAT is being our best friend. (Azure does block pure bridged traffic even when it goes through our VPN.)
This idea is allowing even nested containers to talk to the Internet or our internal network.
I think I’ll just have to set some static routes in order to enable our internal hosts to talk to the containers. I’ll post the result later.