So this blogpost is all about our networking and our built-in firewall. This is intended as a primer for geeks like me who like nitty-gritty details. You don’t need to know ANY of this stuff to use our product or deploy our product. In this first part, I will talk about the raw IP of the container and how that functions. In part 2 I will focus on our built-in firewall controls and how they work.
Firstly, let’s talk about the IP configuration of the container. The Droplet container is configured to be a DHCP client but critically does NOT get that IP address from your DHCP services on the network. Instead, a built-in service is responsible for assigning this IP that requires zero configuration. An ipconfig inside the Droplet container reveals the IP address assigned – incidentally it is always 10.0.2.15 for every container.
Notice the Default Gateway is 10.0.2.2 – this means that any packet outside of this network will be directed to 10.0.2.2. So, the thing to understand here is we by default NAT all traffic out of the container across this IP address which is assigned to the host device. Together with our firewall configuration this effectively “hides” the container on the network making it invisible.
One of the common admin tools to confirm network communications are utilities like tracert and ping. It is possible to ping the Default Gateway address, and get a positive response from the host device – but all other ping/tracert will fail. So, we don’t allow ICMP (the protocol that drives ping/tracert) to escape this host/container network. In the screengrab below the ping of 10.0.2.2 to the Default Gateway works, but all other ping tests fail.
The main takeaway is if you are experiencing networking problems – ping can and does result in false positives indicating a problem – when the issue lies elsewhere. Incidentally, this does not impact other utilities such as nslookup where the requests are driven by a different protocol. In case you don’t know nslookup requests are driven by UDP Port 53. So a nslookup on 192.168.1.1 will give a positive response (assuming a DNS PTR record exists for this reverse lookup). So in the screengrab below, you’ll see a positive answer to the query nslookup 192.168.1.1 and nslookup dc.corp.local
If you look closely, you’ll see the address 10.0.2.3 listed as the “unknown” server. So, a DNS forwarding is taking place on another built-in IP address of 10.0.2.3 which you can see listed if you run an ipconfig /all
So, if a container cannot get to \\dc.corp.local it more likely the case that the host device is misconfigured – or else there’s a problem with DNS where that name either doesn’t exist or is incorrectly configured. A nslookup is probably the most crudest and basic test of connectivity because if you get an answer it proves that the container is forwarding queries to the host device, which in turn is forwarding those requests onto the real DNS infrastructure.
Whilst I’m on the subject of names – one word about using names inside a container. The Droplet container is for the most part completely unaware of your network or domain (both DNS and AD) infrastructure – but it does understand IP and DNS based FQDNs.
[Aside: If you join the container to the domain – the above isn’t true. Our default behavior is the container is a member of its workgroup]
So opening explorer window on \\192.168.1.1 or \\dc.corp.local is highly likely to work – but using \\dc – the short or NETBIOS name is less likely to be successful, and is more likely to be slow. Here’s why. Many years ago, we embraced DNS as the main name resolution system – and most organizations decommissioned the systems that supported the short NETBIOS system that goes back to Microsoft’s NETBIEU protocol (commonly referred to as the less-than-good-old-days :p). NETBIOS names used to be resolved by either a host file, lmhost file or system call WINS (ah remember the days of JetDB driven name resolutions systems!), however, In the absence of these systems, a broadcast packet is probably the only way these shorter names will be resolved. As broadcasts are not proliferated across routers and inhibited by network switches and VLANs, the chances of successful resolution are slim – unless you run a flat network like you would on a simple home-based WIFI network.
What if you have a legacy application is so old, decrepit, and poorly written that it only works with NETBIOS names, and not the face new DNS names that started to be adopted with Windows 2000? Simplez, simply tell it the DNS Suffix information required to complete the short name on the LAN adapter inside the container.
A good way to illustrate this name resolution issue of NETBIOS names is trying an NSLOOKUP on a short name. Here you can see the query of “dc” using nslookup fails:
However, if I manually tell the Droplet container what my preferred domain name is (something it usually gets from domain membership or option 015 DNS Domain Name on your DHCP server) this “problem” goes away…
Of course, the simplest and recommended method of avoiding this issue altogether is to use FQDNs or IP addresses where possible, and avoid the use of NETBIOS names altogether…
So now, we have a good idea of the networking inside the container – what are some practical uses? Here’s one practical example – suppose you have adopted cloud-based solutions such as OneDrive, GoogleDrive, or Dropbox – and you wish to access those systems within the Droplet container. I wouldn’t be recommending installing the software to these systems INSIDE the container, as the synchronization process behind these systems is like starting to fill the container with redundant data. Better to use either our built-in drive redirection to access these or share out the OneDrive/GoogleDrive folder, and then map a network drive to it.
With our drive redirection enabled, any folder accessible on the host device is accessible to the end-user (based on their user login details…) and in this way, the File Manager of the container “mirrors” the File Manager of Windows 10.
So on the left we see the the C, F, L and S drives of the Windows 10 PC, and on the right we see the redirected drives of the Droplet container.
Another approach would be to share the OneDrive folder on the Windows 10 PC, and then map a network drive to the 10.0.2.2 address using that share name. So after sharing out the folder, I can connect to using SMB/CIFS by browsing to \\10.0.2.2 and right-clicking the share, mapping a drive to C: using the standard tools:
