Network Segmentation for Small Networks Using Windows Firewall

Walk into most small businesses running 10 to 50 devices and you'll find the same architecture: one subnet, one broadcast domain, every device talking freely to every other device. The workstation in accounting can reach the security cameras. The guest laptop on WiFi can ping the point-of-sale terminal. A single compromised machine gives an attacker line-of-sight to everything on the network.

This isn't a theoretical risk. It's the default state of nearly every small network that was set up by plugging devices into a switch and calling it done.

The traditional perimeter model assumed that everything inside the firewall could be trusted. That assumption is dead. Perimeter-based networks operate on the belief that all systems within a network can be trusted, but Zero Trust networks eliminate the concept of trust based on network location within a perimeter [3]. Microsoft's Zero Trust deployment guide lists network segmentation and software-defined perimeters as the first and foundational objective to implement — before encryption, visibility, or access control [4].

Federal guidance reinforces the point. NIST SP 800-53 Rev. 5 control SC-7 establishes requirements for monitoring and controlling communications at both external and key internal boundaries of information systems [10]. Not just the edge — the internal boundaries too. CISA's segmentation guidance echoes the same principle: networks without internal segmentation give attackers free lateral movement after initial compromise [8].

The "assume breach" mindset changes how you architect a network. You stop designing for the scenario where the perimeter holds and start designing for the scenario where an attacker is already inside. When every device shares one flat network, that attacker owns everything.

Windows Firewall: The Segmentation Tool You Already Own but Never Configured

Here's the part most small-network admins miss: every Windows machine already ships with a legitimate host-based segmentation tool — and it's turned on by default.

Windows Firewall is a host-based firewall included with the operating system and enabled by default on all Windows editions, supporting Domain, Private, and Public network profiles [1]. Its default behavior blocks all incoming traffic unless it's solicited or matches an existing rule, and allows all outgoing traffic unless a rule explicitly blocks it [1]. Network Location Awareness automatically applies the appropriate security settings based on the network type, with the Public profile enforcing higher security for untrusted networks [1].

Despite this, most administrators either disable it entirely or ignore it. That's a mistake Microsoft explicitly warns against. Disabling Windows Firewall removes the ability to use IPsec connection security rules, strips network fingerprinting protection, disables Windows Service Hardening, and eliminates boot time filters [1]. Going further and stopping the Windows Firewall service itself is not supported by Microsoft and can cause the Start menu to stop working, modern applications to fail to install or update, and phone activation of Windows to fail [2].

Windows Firewall isn't a nuisance popup. It's infrastructure. The problem isn't the tool — it's that almost nobody configures it beyond the defaults.

Macro Segmentation First: Dividing Your Network into Functional Zones

Before diving into firewall rules, you need to divide your network into logical zones. Microsoft recommends macro segmentation — dividing networks into larger functional segments — as a foundation before implementing finer-grained micro-segmentation [4].

The principle is straightforward: organizations should not have one single large pipe in and out of their network. In a Zero Trust approach, networks are segmented into smaller islands where specific workloads are contained, each with its own ingress and egress controls [4].

For a small network, this means creating distinct subnets for distinct functions. Here's a practical starting layout:

• Workstations — 192.168.10.0/24 — Employee desktops and laptops
• Servers — 192.168.20.0/24 — File servers, domain controllers, application servers
• IoT and Printers — 192.168.30.0/24 — Printers, security cameras, badge readers
• Guest WiFi — 192.168.40.0/24 — Untrusted devices with internet-only access

Use CIDR-based subnetting to segment larger address spaces into subnets with network access controls between them [3]. This requires a managed switch that supports VLANs — a one-time investment that most businesses in this size range should already have.

One critical rule: never assign allow rules with broad ranges like 0.0.0.0 through 255.255.255.255. Microsoft warns that these create a false sense of security and are frequently found and exploited by red teams [3]. Every rule should be scoped to the specific subnet, port, and protocol that the traffic requires.

PowerShell Implementation: Subnet-Scoped Firewall Rules Without New Hardware

With your VLANs in place, Windows Firewall becomes your inter-zone traffic controller. Windows Firewall rules can filter traffic based on application name, source and destination IP addresses, IP protocol, source and destination port numbers, interface type, and ICMP traffic type [1]. That gives you enough granularity to build real segmentation policy without buying a dedicated next-generation firewall.

Block workstations from reaching server management ports:

New-NetFirewallRule -DisplayName "Block Workstations to Server RDP" `
  -Direction Inbound `
  -RemoteAddress 192.168.10.0/24 `
  -LocalPort 3389 `
  -Protocol TCP `
  -Action Block `
  -Profile Domain

Allow only specific application traffic between zones:

New-NetFirewallRule -DisplayName "Allow SQL from App Server Only" `
  -Direction Inbound `
  -RemoteAddress 192.168.20.10 `
  -LocalPort 1433 `
  -Protocol TCP `
  -Action Allow `
  -Program "C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Binn\sqlservr.exe" `
  -Profile Domain

Microsoft recommends restricting firewall rules for programs to only the ports they need to operate — if a program tries to listen on a different port, it gets blocked [6]. This is application-aware segmentation using tools already installed on every Windows machine.

For managing rules at scale, PowerShell supports GPO caching for firewall rules, allowing administrators to load a GPO to a local session, make bulk changes, and save them back at once — reducing the burden on domain controllers [2]. Windows Firewall also supports remote management using WinRM and CimSession parameters, so administrators can view and modify firewall rules on remote devices without walking to each machine [2].

Check firewall status across remote machines:

$servers = "SRV01", "SRV02", "SRV03"
$servers | ForEach-Object {
  Invoke-Command -ComputerName $_ -ScriptBlock {
    Get-NetFirewallProfile | Select-Object Name, Enabled
  }
}

Every rule you deploy through Group Policy applies consistently across the domain, turning individual host firewalls into a coordinated segmentation layer.

Domain Isolation with IPsec: Ensuring Only Trusted Devices Communicate

Subnet-based rules control traffic by IP address. But IP addresses can be spoofed, and a rogue device plugged into the right port gets the right address. IPsec domain isolation solves this by shifting segmentation from network-address-based to identity-based.

Windows Firewall supports IPsec, which can require authentication from any device attempting to communicate and can require that network traffic is encrypted to prevent packet sniffing [1]. When configured for domain isolation, domain-joined devices authenticate using Kerberos when communicating with each other and reject non-authenticated inbound connections [2].

In practice, this means a rogue device on the correct subnet — with a valid IP address — still cannot communicate with your domain-joined servers because it cannot present Kerberos credentials. That's micro-segmentation based on machine identity, without buying a single additional product.

For environments running containers or WSL, Hyper-V firewall extends filtering to containers hosted by Windows, including the Windows Subsystem for Linux [5]. This closes a gap that many administrators overlook: a compromised WSL instance on a developer workstation could otherwise bypass host-level firewall rules entirely.

Limiting Blast Radius: The Practical "Assume Breach" Playbook

Each layer described above compensates for the weaknesses of the others. VLANs separate broadcast domains so devices in different zones cannot communicate at Layer 2. Subnet-scoped Windows Firewall rules control which traffic crosses between zones at Layers 3 and 4. IPsec domain isolation verifies the identity of the device, not just its address. Application-specific port restrictions ensure that even authorized traffic is limited to the exact programs and ports required.

This maps directly to Microsoft's Zero Trust network model, which defines three core objectives: prevent unauthorized access, limit the impact of breaches using network segmentation and micro-perimeters, and enhance visibility and control [4]. The "assume breach" principle requires minimizing blast radius by segmenting access by network, user, devices, and application awareness, and verifying all sessions are encrypted end to end [4].

In practice, this layered approach means that an attacker who compromises a workstation in the 192.168.10.0/24 subnet faces a series of barriers:

• The VLAN boundary stops Layer 2 discovery of devices in other zones.
• Firewall rules block connections to server management ports.
• IPsec rejects connections from non-domain-authenticated devices.
• Application rules prevent unauthorized programs from opening network listeners.

For networks where segmentation creates DHCP complexity, DHCP option 82 sub-option 5 allows DHCP relay agents to request IP addresses for clients from a specific subnet when firewall policy restrictions prevent the DHCP server from accessing certain network segments directly [7].

No single layer is unbreakable. But an attacker who must bypass four independent controls to move laterally is far more likely to be detected — and far less likely to reach your critical assets.

Start Today: A Prioritized Action List for Small Network Admins

Every tool referenced in this article is already installed on your Windows machines or available with hardware most small businesses already own. There's no license to buy. Start with the lowest-effort steps and build up:

1. Audit your Windows Firewall status. Verify it's enabled on all three profiles — Domain, Private, and Public — across every machine. Run Get-NetFirewallProfile | Select-Object Name, Enabled on each system. Any machine with a disabled profile is an unguarded entry point.

1. Implement VLANs on your managed switch. Separate workstations, servers, IoT devices, and guest traffic into distinct subnets. This is a one-time configuration change on your switch and DHCP server.

1. Deploy subnet-scoped Windows Firewall rules via Group Policy. Start with the highest-value rules: block workstation subnets from reaching server management ports (RDP, SSH, WinRM). Allow only the specific traffic each zone needs.

1. Implement IPsec domain isolation. Require Kerberos authentication between domain-joined devices. This single policy change prevents any non-domain device from communicating with your servers, regardless of its network position.

1. Document your segmentation policy and review rules quarterly. Segmentation without maintenance becomes security theater. Rules accumulate, exceptions become permanent, and the policy drifts until it no longer reflects reality.

Network segmentation isn't an advanced technique reserved for enterprise networks. It's the foundational security layer that makes every other investment — endpoint protection, monitoring, backup — more effective. The tools are already on your machines. The only missing piece is configuration.