Windows Firewall rules required for InterVLAN communication via VPN

Windows workstations, by default, only allow communication between devices on the same local subnet. This behavior must be explicitly modified via Firewall rules to allow interVLAN communication - disabling the firewall is not sufficient (nor is it recommended).

When to use this article

This article is applicable to your situation if:

There is a VPN in place, whether it's site-to-site or a remote user VPN
- A device on one side of the VPN cannot communicate to a Windows workstation on the other side of the VPN
Or there isn't a VPN in place, but you have a network with multiple VLANs
- A device on one VLAN cannot communicate to a Windows workstation on another VLAN
We control the workstation on the other side (i.e. it's a customer's computer and not something from a software vendor)

Example

Assume you have the following configurations:

Site A: 192.168.1.0/24
- Windows Workstation 1: 192.168.1.100
- Printer 1: 192.168.1.101
Site B: 10.0.0.0/24
- Windows Workstation 2: 10.0.0.200
- Printer 2: 10.0.0.201
Some kind of VPN connectivity between the two sites

By default, Workstation 1 at Site A cannot see anything at Site B unless the VPN is connected. When the VPN is connected, Workstation 1 at Site A will most likely be able to ping and use Printer 2 at Site B. However, Workstation 1 will not be able to ping or access Workstation 2 at Site B.

Windows Workstations vs everything else

This issue is apparently restricted to Windows workstations (and perhaps non-domain joined servers?). All other devices tested at the time of writing (mostly printers from various manufacturers, but also a handful of NAS devices) work without issue.

Why? I don't know exactly and it doesn't matter for the scope of this article. In your head, group devices into Windows workstations vs everything else for the sake of convenience.

(It's something about how the default firewall state is implemented, I guess)

Enabling connectivity

The Windows workstation needs a firewall rule that will allow traffic from the designated subnet(s). You can do this via command line or through the Advanced Firewall Settings GUI

Advanced Firewall Settings GUI method

Open Windows Defender Firewall with Advanced Security
Click Action -> New Rule
Rule Type: Custom
Program: All Programs
Protocol and Ports: leave default
Scope: In the "remote IP Addresses" section, choose "These IP Addresses" and add each remote subnet that you want to allow. In our example above:
1. If you are adding the firewall rule to Workstation 1, remoteip should be 10.0.0.0/24
2. If you are adding the firewall rule to Workstation 2, remoteip should be 192.168.1.0/24
Action: Allow
Profile: All checked
Name: "Allow Subnets"

Command line method

Open an administrative command prompt or powershell and run:

netsh advfirewall firewall add rule name="Allow Subnets" dir=in action=allow protocol=TCP remoteip=192.168.0.0/16 profile=Any

Replace "192.168.0.0/16" with whatever the remote subnet is. In our example above:

If you are adding the firewall rule to Workstation 1, remoteip should be 10.0.0.0/24
If you are adding the firewall rule to Workstation 2, remoteip should be 192.168.1.0/24

Hit Enter and you will get an "Ok" if the command took or some error if it didn't. You should now be able to communicate to that Workstation.

Verifying

When the rule is in place, no additional action is necessary. The rule is automatically enabled. To test, do a ping from a device on the remote subnet to the workstation you just modified - pings should succeed. If pings do not succeed, there is either a different firewall rule preventing the new rule from working (very unlikely) or there is something else going on (VPN isn't connected, firewall at the router level, etc).

Doing this in bulk

The easiest method is to run the command line method via ScreenConnect, since you can run commands on many computers at once and it will queue up for offline computers. The downside is that you will have to run this any time a new computer is added and needs the rule, or when a computer's OS is reloaded.

The better method would be to deploy a firewall rule either via Group Policy (in a domain-joined situation) or via ConnectWise Automate. The benefit is that the firewall policy will be checked and readded if it's ever removed, and it will automatically get applied to new computers for that customer. The downside is that we don't have documentation on this and you (yes, you, the reader) will have to write the documentation for it when you do it the first time. Enjoy!