Please note that the Portmaster only sees and controls connections that are either destined for, or originate from your host from the view of the network. As Virtual Machines and Containers are usually separate entities on the network, the host only forwards their connections just like a router. You can think of them like a virtual data center, where your host is the main router in and out.

The main benefit of an application firewall, which is what the core of the Portmaster is, is to know which application is communicating over the network. VMs and Containers are (put simply) separate operating systems that the Portmaster cannot feasibly look into. This is the primary reason why this network traffic is not checked by the Portmaster.
If you want to have the benefits of the Portmaster within these system, please install the Portmaster there too.

Additionally, there are a multitude of virtualization systems, and each one has their own structure, interfaces, and quirks. Some use special systems that (inadvertently) make it extremely hard to inspect (and control) their network traffic. This immense amount of depth and edge cases is an additional reason why we cannot venture into this area at the moment.

Affected Technologies

To reduce confusion, we will start listing technologies here that are non-obviously affected:

• Windows Subsystem for Linux 2 (WSL2) is affected because it uses a Hyper-V VM.
• Docker (see below for a detailed description)

Docker

On Windows (and OSX) the Portmaster is not capable of intercepting and filtering DNS requests sent from containers as Docker uses a lightweight virtual machine on those platforms.

On Linux, the Portmaster is only able to intercept and filter DNS requests that originate from containers using the hosts networking namespace (i.e. started with --net=host). Containers that run in their own networking namespace get routed through the containers network bridge and never enter the hosts incoming/outgoing netfilter chain. Therefore, the Portmaster does not see the packets sent and received by containers and cannot apply any filtering.

⚠️ If containers are started with --net=host (on Linux) the Portmaster will see and filter connections made by processes in this containers but due an issue with the binary path lookup it may use the wrong profile for the binary that initiated the connection. (i.e. it may use the profile for a binary at path /usr/bin/curl at the host while the container's "curl" is a different binary) ⚠️

We will re-evaluate this scoping decision at some point in the future. If you have any thoughts about that, please tell us.

We are also working on a good way to communicate this to users where they most need to know about that. If you have any suggestions, please leave a comment.