<div>
First, I'm unsure why you'd dockerize your apps since your running a container already.<br />
<br />
Simple solution is don't run docker. You're already containered using LXD.<br />
<br />
That said, if I had to debug this, I'd first check my networking in my docker container.<br />
<br />
Likely it's some minor routing problem. You'll have to arrange for your packets to flow through your LXD network stack to your machine network stack.<br />
<br />
How this is done is highly dependent on all commands you issued to get to where you are now.<br />
<br />
Also, keep in mind, all work you do on Zesty, will likely require a complete rethink, when you upgrade to Artful or Bionic, as both these scrape current networking + switch to using netplan (shudder).<br />
<br />
If at all possible, skip docker + just run your application native in LXD.<br />
<br />
If you must run docker, then install tshark... let's see... I'd likely install it at machine level + compare how packet flow was working from LXD to machine + how it was broken when flowing from docker to LXD.
</div>


<div>
The thing is this.. &nbsp;Developers/vendors sometimes ship applications via Docker... I can run one command and deploy a complex application.. &nbsp;Now.. &nbsp;Docker natively is a problem for me.. &nbsp;This being due to the fact on one VM I wish to run a different versions of different PHP, MySQL, and even different VLANs/networks... &nbsp;So.. This is where LXD containers make sense.. &nbsp;The perfect scenario will be to run LXD containers and then pull Docker images down to in return create Docker containers nested in &nbsp;a LXD container. &nbsp;I'll build a lab for this.. I have a use case...
</div>


<div>
After reviewing this further I agree 100%. &nbsp;If I have a Developer that wants to work in docker I'll spin up a dedicated VM for his use... That single VM will be for his docker apps.. &nbsp;I'll create my own registry and the developer can package and ship directly to me across the datacenters securely. &nbsp;Other than that I'm sticking with LXD containers. &nbsp;They are awesome... &nbsp;I already moved 4 x network appliances and my Atlassian Confluence app within one VM that is the LXD host. I saved 6 GBs of RAM already.. &nbsp;And.. &nbsp;It's easier to manage for in the past I would have to add each VM to my VEEAM tape backup job, VEEAM disk to disk job, and Nimble Storage snapshot job. &nbsp;I have so many VMs it becomes hard to manage. &nbsp;This one LXD host will end up hosting 10+ network appliances and my Atlassian Confluence app... &nbsp;I built a series of bridged NICs that present the container to their respective vSwitch in vSphere. &nbsp;I don't see any performance hit either... &nbsp;Now.. &nbsp;In my other environments where I don't have Hypervisor access I'll be able to create my own nested Hypervisor and give myself an experience I didn't have before... &nbsp;This being environments where I lease VMs on a per month basis... &nbsp;The fact I'll be able to take snapshots nested on someone else's Hypervisor is golden... &nbsp;In the past I would have to open a ticket with the data center and request a snapshot for ease of roll back... &nbsp;In addition to that no more creating VMs on their Hypervisor... &nbsp;I'll just spin up a container.. &nbsp;I love it... &nbsp;LXD is amazing and to be honest so is Windows Containers. &nbsp;Once their Linux kit is in production I'll be doing a lot in Windows Containers...
</div>


<div>
Oh certainly yes.<br />
<br />
I didn't think you might have been referring to some developer asking for this type of setup.<br />
<br />
Yep, for me LXD resolved all my client hosting problems + allows me to run a large hosting company with a handful of people.<br />
<br />
Before LXD, if one site had run away resource usage, determine the site + exact problem was complex + time consuming.<br />
<br />
With LXD, these types of problems tend to be faster + simpler to resolve.
</div>


<div>
<div class="content wysiwyg-content">
My LXD host is running Ubuntu 17.04. &nbsp;I created a bridged interface and set that interface as the default network for all LXD containers... &nbsp;This results in my containers being on my LAN.. &nbsp;This works just fine, however, I'm now trying to run Docker inside a LXD container. &nbsp;My goal is to place all Docker container on the same LAN. &nbsp;How can I create a Docker network to be on the same LAN while nested on a LXD container?
</div>
</div>


My LXD host is running Ubuntu 17.04.  I created a bridged interface and set that interface as the default network for all LXD containers...  This results in my containers being on my LAN..  This works just fine, however, I'm now trying to run Docker inside a LXD container.  My goal is to place all Docker container on the same LAN.  How can I create a Docker network to be on the same LAN while nested on a LXD container?

Running Docker Inside A LXC Container - Bridged to existing LAN

LXC is an operating system-level virtualization method for running multiple isolated Linux systems (containers) on a single control host. LXC provides operating system-level virtualization by providing a virtual environment that has its own process and network space. LXC relies on the Linux kernel cgroups functionality. LXC is similar to other OS-level virtualization technologies on Linux such as OpenVZ and Linux-VServer, as well as those on other operating systems such as FreeBSD.

Networking is the process of connecting computing devices, peripherals and terminals together through a system that uses wiring, cabling or radio waves that enable their users to communicate, share information and interact over distances. Often associated are issues regarding operating systems, hardware and equipment, cloud and virtual networking, protocols, architecture, storage and management.

Networking

Docker is a computer program used to run software packages called containers in an operating-system-level virtualization process called containerization. It’s developed by Docker, Inc. and was first released in 2013.