Network Segmentation and Subnet Isolation

Network Segmentation and Subnet Isolation

Network segmentation puts devices in separate subnets, letting firewalls enforce which segments can talk to each other.¹

A flat network where every device shares one subnet makes it trivial for a compromised device to scan and attack others. Segmentation limits this blast radius: a ransomware infection on a workstation in the user VLAN cannot directly reach servers in the production VLAN if a firewall blocks inter-segment traffic. Security zones (DMZ, production, management, IoT, and guest) each get a dedicated subnet and defined ingress/egress rules.

Security zone design

Inside a segmented network, each zone holds devices with similar trust levels.¹ The DMZ (Demilitarized Zone) contains servers exposed to the internet, such as web servers and mail relays, behind one firewall interface. The production zone holds internal servers that require internet access for updates but no direct inbound exposure. The management zone holds network infrastructure: switches, routers, firewalls, and monitoring servers. IoT devices, including sensors, cameras, and smart appliances, belong in an isolated zone that blocks lateral movement to other segments. Guest networks sit in their own subnet with internet-only access. Building on this, each zone boundary is a firewall rule: default deny between zones, with explicit permit rules for the specific ports each service requires.²

DMZ and internet-facing workload placement

The DMZ sits between the public internet and the internal network, exposing only the servers that need inbound connectivity. Web servers, mail relays, and DNS forwarders belong here. Production servers that initiate outbound connections for updates do not need to sit in the DMZ because they accept no inbound traffic from outside. CapyToolkit calculates the smallest prefix that fits your DMZ server count, so you can allocate a tight /28 or /29 without wasting address space on unused IPs.

CIDR allocation for segmentation

Allocating subnets for a segmented network starts with choosing a parent block. A 10.0.0.0/16 provides 256 /24 subnets for zone expansion.³ Each zone gets a /24 or smaller based on device count: management at 10.0.0.0/28 (11 usable in cloud, 14 on-premises), DMZ at 10.0.1.0/28, production at 10.0.10.0/24, IoT at 10.0.20.0/24, guest at 10.0.30.0/24. Consequently, the second octet encodes the zone tier in the addressing scheme, making routing table entries and firewall rules readable at a glance. Building on this, each /24 zone provides 254 usable addresses, enough for hundreds of devices per zone with room to grow without reassigning subnets.

Addressing scheme for multi-zone networks

CapyToolkit shows the network address, broadcast, and usable range for each subnet you plan, which makes it easy to verify that your chosen scheme fits within the parent block without overlaps. A consistent numbering convention keeps firewall rules readable as the network grows from 5 zones to 50. For example, using the third octet for the zone ID means production-1 is 10.0.10.0/24, production-2 is 10.0.11.0/24, and so on in a predictable pattern that any network engineer can follow.

Firewall rules and subnet-based access control

Subnet-level firewall rules are simpler and less error-prone than per-device rules.³ A single rule blocking 10.0.20.0/24 (IoT zone) from reaching 10.0.10.0/24 (production zone) isolates all current and future IoT devices without updating the rule each time a device is added. Building on this, the jump host pattern places a single bastion server in the management zone, and all administrative SSH and RDP access passes through it. Consequently, blocking direct SSH to production from every other zone except management-to-production on port 22 reduces the attack surface to one controlled entry point. Furthermore, logging all inter-zone deny hits on the firewall builds a baseline of normal traffic patterns, making anomalous lateral movement visible in security logs.

Jump host and bastion patterns

A bastion server in the management zone acts as the sole entry point for administrative access to production and database zones. All SSH and RDP sessions originate from the bastion, which logs every connection for audit purposes. CapyToolkit confirms the bastion subnet is large enough for the bastion instance and its ENIs without consuming address space needed by other management services.

The bastion itself should never accept SSH or RDP from an unrestricted source. AWS security group guidance recommends authorizing only the specific IP address ranges that need administrative access on ports 22 and 3389, rather than opening 0.0.0.0/0, since a bastion reachable from any address becomes the single point of failure for the entire access-control model. Pairing this restriction with a dedicated /29 or /30 for the bastion's own management interface keeps the exposed surface as small as the subnet math allows.

Micro-segmentation with host-based firewalls

Traditional network segmentation stops at the subnet boundary, but a compromised host within a segment can still attack its peers. Micro-segmentation moves the enforcement point to each individual host using host-based firewalls (Windows Defender Firewall, iptables, or cloud security groups). Each workload receives a policy that defines exactly which other workloads it can communicate with, regardless of subnet membership.

In AWS, security groups provide micro-segmentation at the ENI level: an EC2 instance in a public subnet can have a security group that only allows inbound 443 from a specific load balancer security group, not from the entire subnet.⁴ Building on this, Azure NSGs can be applied at both the subnet level and the NIC level, giving two layers of enforcement. For Kubernetes, NetworkPolicies restrict pod-to-pod traffic within the cluster, complementing the subnet-level segmentation that isolates node pools. Consequently, combining subnet-level zones with host-based micro-segmentation creates a defense-in-depth architecture where breaching one layer does not grant unrestricted access.

Zero Trust principles and subnet design

Zero Trust architecture assumes no network location is inherently trustworthy, which changes how you design subnets. Instead of a trusted internal zone and an untrusted external zone, every segment enforces authentication and authorization on each connection. Subnets in a Zero Trust design are smaller and more numerous: each application tier (web, API, database) gets its own segment, and lateral movement between tiers requires explicit policy.

Implementing Zero Trust with subnets means assigning /28 or /29 blocks to individual application components rather than placing everything in a shared /24.⁵ Building on this, identity-aware proxies (like Google BeyondCorp or Azure Private Access) replace VPNs by authenticating each user and device before granting access to a segment, regardless of where the connection originates. The subnet calculator helps you plan these smaller allocations: a /28 provides 11 usable addresses in AWS, enough for a single microservice's instances with headroom for rolling deployments. Consequently, the subnet calculator helps you isolate IoT devices into their own /28 segment, trading address efficiency for security granularity, which is the correct priority for regulated workloads.

When to use this

Use this guide when designing network architecture for a new environment or adding isolation to a flat network. Your organization needs to limit the damage from a compromised device reaching other segments.

Examples