To add a Windows firewall rule targeting a specific network interface, use PowerShell with the New-NetFirewallRule cmdlet and specify the -InterfaceAlias parameter. This allows you to restrict traffic to or from an adapter like "Ethernet" (the Windows equivalent of Linux's eth0), ensuring that rules only apply to the intended connection path rather than all interfaces.
Understanding Interface Aliases in Windows
In Linux, network interfaces are often referred to by names likeeth0, wlan0, or lo. Windows handles this differently, using dynamic names based on the hardware manufacturer or user customization, such as "Ethernet," "Wi-Fi," or "Local Area Connection." However, behind the scenes, both operating systems manage these connections through distinct adapters that have unique identifiers.
When configuring a firewall rule in Windows, you do not typically reference the interface by its display name alone if you want precision. Instead, you can target the interface alias directly. This is crucial when you have multiple active connections, such as a wired Ethernet connection and a Wi-Fi connection, and you want to ensure a firewall rule only affects one of them. For instance, you might want to allow SSH access only over your wired connection for security reasons, while blocking it on Wi-Fi.
The primary tool for managing these settings in modern Windows versions is PowerShell. The built-in netsh command-line utility has been largely superseded by the NetSecurity module, which offers more granular control over interface-specific rules. Understanding how to map your physical or virtual adapter to its alias is the first step in creating precise firewall policies.
Identifying Your Network Interface Alias
Before creating a rule, you must identify the exact alias of the network interface you wish to target. You can retrieve this information using PowerShell. Open PowerShell as an administrator and run the following command:Get-NetAdapter | Select-Object Name, Alias, Status
This command lists all network adapters installed on your system along with their status. Look for the adapter corresponding to your desired connection (e.g., the one connected to your LAN). The Name column shows the user-friendly name, while the Alias column provides the identifier used internally by networking services. In many cases, the alias matches the name, but it is best practice to use the value returned here to avoid errors.
If you need to find the IP address associated with that interface to further refine your rule, you can pipe the output:
(Get-NetIPAddress -InterfaceAlias "Ethernet").IPv4Address
Replace "Ethernet" with the actual alias you found. This helps in verifying that you are targeting the correct logical interface before applying restrictive rules.
Creating the Firewall Rule via PowerShell
Once you have identified the interface alias, you can create a new inbound or outbound firewall rule. TheNew-NetFirewallRule cmdlet is the standard method for this task. Below is an example of creating an inbound rule that allows TCP traffic on port 80 specifically for the "Ethernet" interface.
New-NetFirewallRule `
-DisplayName "Allow HTTP on Ethernet" `
-Direction Inbound `
-Action Allow `
-Protocol TCP `
-LocalPort 80 `
-InterfaceAlias "Ethernet"
Let's break down the parameters:
- -DisplayName: A human-readable name for the rule, visible in the Windows Defender Firewall console.
- -Direction: Specifies whether the rule applies to inbound (incoming) or outbound (outgoing) traffic.
- -Action: Defines what happens when traffic matches the rule. Common values are
Allow,Block, orBypass. - -Protocol: The protocol type, such as
TCP,UDP, orICMPv4. - -LocalPort: The port number to target. You can specify ranges (e.g., 8000-9000) or multiple ports.
- -InterfaceAlias: This is the critical parameter that mimics the Linux interface specificity. It restricts the rule to the named adapter.
-Action Allow to -Action Block. This approach gives you the same level of control that Linux administrators enjoy when filtering traffic at the eth0 level.
Verifying and Managing Existing Rules
After creating the rule, it is important to verify that it has been applied correctly. You can list all firewall rules filtered by the interface alias to ensure your changes took effect.Get-NetFirewallRule | Where-Object {$_.InterfaceAlias -eq "Ethernet"} | Format-Table DisplayName, Direction, Action
This command filters the global list of firewall rules to show only those associated with the "Ethernet" adapter. Review the output to confirm that your new rule appears with the correct direction and action. If you made a mistake, you can remove the rule using:
Remove-NetFirewallRule -DisplayName "Allow HTTP on Ethernet"
Always test your configuration by attempting to connect to the service or resource you intended to allow or block. Use tools like Test-NetConnection to diagnose connectivity issues related to your specific interface. For more complex scenarios involving DNS resolution or broader network troubleshooting, consider reviewing related guides on DNS and NSLOOKUP: Troubleshooting Network Connectivity Issues to ensure your underlying network stack is functioning correctly alongside your firewall rules.
Advanced Scenarios and Best Practices
While basic interface targeting is straightforward, advanced users may need to combine interface rules with other criteria. For example, you might want to allow traffic only from a specific IP address on a specific interface. You can achieve this by adding the-RemoteAddress parameter to the New-NetFirewallRule command.
Additionally, be aware that interface aliases can change if network adapters are disabled, re-enabled, or replaced. Dynamic naming in Windows can sometimes lead to unexpected behavior if scripts rely on static names. To mitigate this, some administrators prefer to bind rules to the -InterfaceDescription or use GUIDs where possible, though InterfaceAlias remains the most common and reliable method for general administration.
For users looking to implement stricter network isolation, such as blocking all outgoing connections except for specific trusted endpoints, you might explore strategies detailed in How can I block all outgoing windows connection but allow connect to a specific IP address. Combining broad interface restrictions with specific IP whitelisting creates a robust defense-in-depth strategy.
Finally, always document your firewall changes. Maintaining a clear record of why a rule was added, which interface it targets, and when it should expire helps prevent rule bloat and makes future troubleshooting significantly easier. Regular audits of your Get-NetFirewallRule output ensure that obsolete rules do not linger and potentially expose your system to unnecessary risks.
Frequently Asked Questions
What is the Windows equivalent of eth0?
The direct equivalent depends on your hardware, but it is usually named "Ethernet" for wired connections or "Wi-Fi" for wireless ones. You can find the exact internal alias by running Get-NetAdapter in PowerShell.
Can I apply a firewall rule to multiple interfaces at once?
No, the -InterfaceAlias parameter accepts only a single string value. To apply the same rule to multiple interfaces, you must create separate rules for each alias or omit the parameter to apply it globally.
Why is my firewall rule not working on my specific interface?
This often happens if the interface alias has changed due to driver updates or hardware swaps. Verify the current alias using Get-NetAdapter and update your rule's -InterfaceAlias parameter accordingly.
How do I delete a firewall rule created via PowerShell?
You can remove a rule by its display name using the command Remove-NetFirewallRule -DisplayName "Your Rule Name". Ensure you have administrative privileges to execute this removal.
Does this method work on Windows Server?
Yes, the NetSecurity module and New-NetFirewallRule cmdlet are available in Windows Server 2012 R2 and later versions, providing the same interface-specific control as in client versions of Windows.