How to Configure Hyper-V Firewall Rules in Windows 11 Using PowerShell

As developer workstations and enterprise endpoints rely increasingly on virtual machines, Windows Sandbox, and Windows Subsystem for Linux (WSL 2), traditional host-level firewall rules often struggle to provide granular isolation for virtualized workloads. In Windows 11, Microsoft introduced the Hyper-V firewall—a stateful packet filtering layer implemented directly inside the Hyper-V Virtual Switch (vSwitch). Using the NetSecurity module in PowerShell, system administrators and developers can configure dedicated Hyper-V firewall rules that enforce inbound and outbound restrictions on virtual network adapters without altering the primary Windows host firewall profile.

Understanding Hyper-V Virtual Switch Firewall Architecture

Historically, Windows Defender Firewall operated primarily on the host network interfaces. When a local Hyper-V virtual machine or WSL 2 Linux distribution bridged or NAT-routed traffic across a virtual switch, host-level rules were evaluated either before or after virtual switch routing, making it difficult to restrict traffic entering or exiting specific virtualized guests.

The Hyper-V firewall addresses this limitation by hooking directly into the virtual switch filtering platform. Each virtual network adapter attached to a vSwitch is assigned a unique port ID and interface identifier. By binding rules directly to Hyper-V vSwitch profiles, administrators can block malicious outbound connections from compromised containers, isolate multi-tier local VM labs, and protect development databases running inside WSL 2 from reaching external subnets.

Auditing Existing Hyper-V Firewall Profiles

Before applying custom rules, verify the status of the Hyper-V firewall profiles across your system. Launch an elevated PowerShell session by right-clicking Start and selecting Terminal (Admin).

Execute the Get-NetFirewallHyperVVMSetting cmdlet to query the configuration of your local virtual machines:

Get-NetFirewallHyperVVMSetting | Format-Table Name, Enabled, DefaultInboundAction, DefaultOutboundAction

By default, newly provisioned virtual adapters allow both inbound and outbound traffic. You can inspect the global virtual switch firewall state across all local virtual adapters using:

Get-NetFirewallHyperVRule | Format-Table Name, DisplayName, Direction, Action, Enabled

If no custom rules have been provisioned yet, the command returns default system traversal rules.

Creating an Inbound Hyper-V Firewall Rule

To restrict inbound traffic destined for a virtual machine or container running on the Hyper-V virtual switch, use the New-NetFirewallHyperVRule cmdlet. Rules can target specific protocols, ports, and virtual network adapter ports.

For example, to permit incoming SSH traffic (TCP port 22) to a development Linux VM connected to the virtual switch named "Default Switch", execute:

New-NetFirewallHyperVRule -DisplayName "Allow-WSL-SSH-Inbound" `
    -Direction Inbound `
    -Action Allow `
    -Protocol TCP `
    -LocalPort 22 `
    -Enabled True

This rule evaluates stateful inbound packets arriving at the virtual switch and permits TCP port 22 handshakes through to the virtual guest.

Restricting Outbound Traffic from Virtual Machines

In zero-trust or malware analysis environments, you frequently need to ensure that virtualized workloads cannot initiate arbitrary outbound connections to the corporate intranet or external cloud services.

To create an outbound block rule that prevents all virtual machines from accessing sensitive database ports (such as Microsoft SQL Server port 1433) on the host’s corporate subnet (192.168.1.0/24), run:

New-NetFirewallHyperVRule -DisplayName "Block-VM-Corporate-SQL-Outbound" `
    -Direction Outbound `
    -Action Block `
    -Protocol TCP `
    -RemoteAddress 192.168.1.0/24 `
    -RemotePort 1433 `
    -Enabled True

Any connection attempt originating inside a virtual machine toward port 1433 on that remote IP range is dropped at the virtual switch level, generating a blocked packet event.

Binding Hyper-V Firewall Rules to Specific Virtual Machines

When multiple virtual machines and WSL 2 distributions share a single virtual switch, applying global rules may restrict guests that require broader access. You can isolate rules to a specific virtual machine by specifying its VM ID or targeting its specific virtual switch port.

First, retrieve the VM ID of your target guest using Get-VM:

$VM = Get-VM -Name "Ubuntu-DevServer"
$VM.Id.Guid

Then create a targeted Hyper-V firewall rule associating that unique ID:

New-NetFirewallHyperVRule -DisplayName "Isolate-Ubuntu-DevServer-Web" `
    -Direction Inbound `
    -Action Allow `
    -Protocol TCP `
    -LocalPort 80, 443 `
    -VMId $VM.Id.Guid `
    -Enabled True

Only network traffic addressing the virtual switch port mapped to Ubuntu-DevServer is evaluated against this rule, leaving other VMs unaffected.

Enforcing Default Inbound Block Policies on Virtual Adapters

For maximum security, you can configure a virtual machine’s virtual adapter to operate in default-deny mode for all inbound traffic, allowing only explicitly whitelisted ports.

Update the inbound policy for a specific VM using Set-NetFirewallHyperVVMSetting:

Set-NetFirewallHyperVVMSetting -Name $VM.Id.Guid -DefaultInboundAction Block

Once set, all unsolicited incoming traffic to that virtual machine is dropped unless explicitly permitted by an enabled NetFirewallHyperVRule.

Modifying, Disabling, and Deleting Hyper-V Rules

To disable a rule temporarily during testing without deleting its configuration, use Disable-NetFirewallHyperVRule:

Disable-NetFirewallHyperVRule -DisplayName "Block-VM-Corporate-SQL-Outbound"

To re-enable it:

Enable-NetFirewallHyperVRule -DisplayName "Block-VM-Corporate-SQL-Outbound"

When a rule is no longer required, delete it cleanly using Remove-NetFirewallHyperVRule:

Remove-NetFirewallHyperVRule -DisplayName "Allow-WSL-SSH-Inbound" -Confirm:$false

Deploying native Hyper-V firewall rules via PowerShell provides a robust, native security boundary for modern virtualization and containerized workflows in Windows 11.