Change Default Container's Network Outbound policy to DENY-ALL

[winkingturtle-vmw]

What is your question?
After Reading this document , it mentions that Default Outbound: ALLOW ALL for Windows Server Containers. It also mentions that it's possible to change the default for HNSNetwork to be DENY-ALL. We tried changing all firewall networks to Block, but that didn't have any effect on the NAT network and containers created underneath it. Can you please point us to correct syscall/powershell/documentation that will change the default back to DENY-ALL ? DENY-ALL is the default behavior for Windows Server 2019.

[github-actions]

Thank you for creating an Issue. Please note that GitHub is not an official channel for Microsoft support requests. To create an official support request, please open a ticket here. Microsoft and the GitHub Community strive to provide a best effort in answering questions and supporting Issues on GitHub.

[winkingturtle-vmw]

Pinging to keep this issue open

[winkingturtle-vmw]

Pinging to keep this issue open

[winkingturtle-vmw]

Pinging to keep this issue open

[winkingturtle-vmw]

Pinging to keep this issue open

[winkingturtle-vmw]

Pinging to keep this issue open

[sureshbabu-msft]

Hi Amin Jamali (@winkingturtle-vmw), Thank you for your patience — we've investigated this in detail. Here's a summary of our findings and recommendations:

Why Windows Firewall Changes Don't Work

The outbound policy for NAT-networked containers is controlled at the HNS/VFP layer, not the Windows Firewall layer. Modifying firewall profiles (even setting all to "Block") has no effect on container traffic in NAT mode. The Network Isolation and Security (https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/network-isolation-security) doc references this but doesn't provide actionable steps — we acknowledge that gap.

Recommended Workaround: HNS Endpoint ACL Policies

For process-isolated containers, you can apply a DENY-ALL outbound policy per container using HNS endpoint ACL policies. This has been tested and confirmed to block all outbound traffic (including DNS).

You can apply an ACL policy with Action=Block, Direction=Out, Protocol=256 (Any) to the container's HNS endpoint using Get-HnsEndpoint and Invoke-HNSRequest. This must be applied per container endpoint — there is currently no network-wide default DENY-ALL configuration option for NAT networks.

Hyper-V Isolation Limitation

For Hyper-V isolated containers using NAT networking, HNS ACL policies do not take effect due to a platform limitation — the default port ACLs cannot be reconfigured (https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/network-isolation-security) in NAT and Transparent modes for Hyper-V isolation. As an alternative, L2Bridge networking can be considered, where VFP-based ACL enforcement is expected to be more effective.

Kubernetes Environments

If you are running Windows containers in Kubernetes with Calico, you can enforce egress deny-all using a Kubernetes Network Policy
(https://docs.tigera.io/calico/latest/network-policy/get-started/kubernetes-policy/kubernetes-network-policy).

We hope this helps unblock your scenario. Please let us know if you have further questions.

[winkingturtle-vmw]

Thank you sureshbabu-msft for your response. I believe you may have ran your tests against Windows Server 2022 or 2019. As replied in this issue (#616) applying ACLPolicy for HNSEndpoint is broken Windows Server 2025.

[sureshbabu-msft]

Hi Amin Jamali (@winkingturtle-vmw), thank you for the follow-up and for pointing out the ACLPolicy issue on Windows Server 2025.

Since the underlying ACLPolicy/HNSEndpoint issue on Windows Server 2025 is already being tracked in #616, we are closing this issue to consolidate the discussion and avoid duplication. Any updates and fixes related to ACLPolicy enforcement will be tracked there.

Please continue to follow #616 for progress on this. If you have additional questions or scenarios beyond what's covered in #616, feel free to open a new issue.

Thank you for your patience and for helping us identify this gap.