Repository navigation
Change Default Container's Network Outbound policy to DENY-ALL #617
Description
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.
Activity
github-actions commentedon Oct 6, 2025
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 commentedon Nov 7, 2025
Pinging to keep this issue open
winkingturtle-vmw commentedon Dec 9, 2025
Pinging to keep this issue open
winkingturtle-vmw commentedon Jan 12, 2026
Pinging to keep this issue open
winkingturtle-vmw commentedon Feb 17, 2026
Pinging to keep this issue open
winkingturtle-vmw commentedon Mar 23, 2026
Pinging to keep this issue open
sureshbabu-msft commentedon Apr 13, 2026
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 commentedon Apr 13, 2026
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 commentedon Apr 16, 2026
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.