Design network segmentation that contains blast radius and limits lateral movement. Covers micro-segmentation, VLAN design, firewall zones, east-west traffic control, zero-trust segmentation, and the patterns that prevent network breaches from spreading.
Network segmentation divides a network into smaller, isolated subnetworks to control traffic flow, improve security, and reduce latency. It matters when systems must communicate across trust boundaries—such as between public-facing services and internal databases, or between microservices in different environments. This page details patterns for designing, implementing, and maintaining network segmentation across modern distributed systems, focusing on decisions that shape performance, resilience, and operational clarity.
Organize network segments around functional zones: public, DMZ, internal, database, storage, and management. Use VLAN IDs and IP subnets to define boundaries and enforce routing.
Assign VLANs to zones using standard tagging on switches. Configure trunk ports to carry multiple VLANs:
interface Gi1/0/1
switchport mode trunk
switchport trunk allowed vlan 10,20,30
switchport trunk native vlan 1Each zone has a dedicated subnet. Assign IP ranges, gateways, and DNS entries accordingly:
Hosts in a zone use the zone's gateway for inter-zone traffic. Configure routing tables to resolve cross-zone paths:
# On a host in the internal zone
ip route add default via 10.0.3.1
ip route add 10.0.2.0/24 via 10.0.3.1
ip route add 10.0.4.0/24 via 10.0.3.1Silent failure: A service in the internal zone fails to reach the database zone when the gateway is unreachable. The default route is not updated after a switch reboot, and the host continues using a stale ARP cache for the gateway. The fix requires arp -d 10.0.3.1 and ip route flush cache.
Enforce policy at zone boundaries using firewalls and ACLs. Define ingress and egress rules per zone pair.
A firewall rule allows HTTP traffic from public to DMZ:
{
"name": "public-to-dmz-http",
"source": "10.0.1.0/24",
"destination": "10.0.2.0/24",
"protocol": "tcp",
"port": 80,
"action": "allow",
"log": true
}Apply rules to firewall interfaces or zone pairs. For example, a rule from DMZ to internal zone permits HTTPS and SSH:
# Example rule in a Linux firewall (nftables)
table inet firewall {
chain input {
type filter hook input priority 0; policy accept;
iif "dmz" tcp dport 443 accept
iif "dmz" tcp dport 22 accept
}
chain forward {
type filter hook forward priority 0; policy accept;
iif "dmz" oif "internal" accept
}
}Common confusion: iif (input interface) vs. oif (output interface) in firewall rules. Misplacing the direction of traffic leads to services being unreachable, especially when NAT or load balancing is involved. A web server in the DMZ cannot reach the internal database because the forward chain uses iif "dmz" but the traffic is tagged with oif "internal" after a load balancer.
Sharp edge: A firewall rule allows traffic from internal to database but does not enable stateful tracking. As a result, TCP connections initiated from internal are established, but responses from database to internal are dropped. The fix is to enable connection tracking:
# Enable conntrack in nftables
table inet firewall {
chain input {
ct state established,related accept
}
chain forward {
ct state established,related accept
}
}Isolate services into dedicated subnets with dedicated IP pools and virtual IPs (VIPs). Use VIPs for high-availability and load balancing.
Define a VIP pool for a database cluster:
{
"service": "database",
"vip": "10.0.4.100",
"subnet": "10.0.4.0/24",
"members": [
"10.0.4.101",
"10.0.4.102",
"10.0.4.103"
],
"health_check": {
"interval": "30s",
"timeout": "10s",
"url": "/health"
}
}Configure a load balancer to distribute traffic to the members. For example, using HAProxy:
frontend db_frontend
bind *:3306
mode tcp
default_backend db_backend
backend db_backend
balance roundrobin
option tcplog
server db1 10.0.4.101:3306 check
server db2 10.0.4.102:3306 check
server db3 10.0.4.103:3306 checkSilent failure: A new database node is added but does not appear in the load balancer’s active pool. The health check URL returns 200 but the load balancer expects {"status": "ok"}. The response body is {"status": "healthy"}. The load balancer marks the node as down due to a mismatch in expected JSON structure.
Sharp edge: VIPs are assigned via ARP announcements. When a load balancer fails over, it must announce the VIP via gratuitous ARP to ensure clients use the new active node. The default ARP timeout is 30 seconds, so client traffic may stall for up to that duration during a failover.
Deploy isolated networks per environment—development, staging, production—using overlay networks like VXLAN or GRE.
Configure VXLAN tunnels between hosts:
# Create VXLAN interface on a host
ip link add vxlan0 type vxlan id 100 local 192.168.1.10 remote 192.168.1.20 dstport 4789
ip link set vxlan0 up
ip addr add 10.10.0.1/24 dev vxlan0Each environment uses a unique VXLAN ID:
Common confusion: Using the same subnet across environments. A service in staging (10.11.0.0/24) cannot reach a production service (10.12.0.0/24) even when both are on the same physical network. The root cause is that VXLAN packets are not being properly routed at the outer network layer. The fix is to configure a gateway for the overlay network:
# On a gateway host
ip route add 10.10.0.0/24 via 192.168.1.10 dev eth0
ip route add 10.11.0.0/24 via 192.168.1.10 dev eth0
ip route add 10.12.0.0/24 via 192.168.1.10 dev eth0Sharp edge: VXLAN headers are not preserved when traversing NAT or firewalls. A packet from a development service to a staging service may have its outer IP header modified by a NAT gateway, causing the inner VXLAN packet to be misrouted. The solution is to configure the NAT gateway to preserve UDP ports and to enable checksum offloading for VXLAN.
Integrate network segmentation with application layer logic using a service mesh. Define traffic policies per service or group.
Define a mesh policy to isolate the payment service from other services:
apiVersion: network.mesh/v1
kind: TrafficPolicy
metadata:
name: payment-isolation
spec:
destination:
service: payment-service
ingress:
- name: "external"
source: "public"
ports:
- 80
- 443
- name: "internal"
source: "internal"
ports:
- 8080
egress:
- name: "database"
target: "database"
ports:
- 5432
- name: "analytics"
target: "analytics"
ports:
- 9000
tls:
- name: "mTLS"
mutual: true
mode: "permissive"Silent failure: A service mesh does not enforce mutual TLS between the payment service and its database. The database responds with a certificate, but the payment service does not verify it. The result is untrusted connections and a failure in transaction processing. The fix is to ensure that both sides present valid certificates and that the mesh controller validates the certificate chains.
Sharp edge: Service mesh policies are evaluated in order. A late-arriving policy overrides earlier ones, but the order is not always clear. A developer deploys a new service mesh policy that applies to all services but forgets to set match: service: "payment-service" in the destination field. As a result, the policy applies to all services, but the payment service receives unexpected behavior due to overlapping rules.
Use DHCP to dynamically assign IP addresses from predefined pools based on role, environment, or service.
Define a DHCP scope for web servers in production:
{
"scope": "production-web",
"range": "10.12.1.100-10.12.1.200",
"gateway": "10.12.1.1",
"dns": [
"10.12.1.10",
"10.12.1.11"
],
"options": {
"router": "10.12.1.1",
"domain-name": "example.com",
"domain-name-servers": [
"10.12.1.10",
"10.12.1.11"
]
}
}On a DHCP server (e.g., ISC DHCP), configure the scope:
subnet 10.12.1.0 netmask 255.255.255.0 {
range 10.12.1.100 10.12.1.200;
option routers 10.12.1.1;
option domain-name-servers 10.12.1.10, 10.12.1.11;
option domain-name "example.com";
default-lease-time 600;
max-lease-time 7200;
}Silent failure: A new web server boots but receives an IP from the wrong pool. The DHCP server sends a DHCPNAK packet with status: "failed" and message: "IP address not available". The cause is that the IP pool is exhausted, and the server did not receive a DHCPACK with a lease.
Sharp edge: DHCP servers must be synchronized across multiple instances. A primary DHCP server fails, and a secondary takes over, but the secondary has a different lease database. Clients continue using old leases, but new clients get inconsistent configurations. The fix is to use a shared database (e.g., PostgreSQL) and a heartbeat mechanism between servers.
Monitor segmentation health with tools that observe traffic, reachability, and policy enforcement.
Use tcpdump to capture traffic between zones:
# Capture traffic between DMZ and internal zones
tcpdump -i any -n -s 0 -w dmz-to-internal.pcap \
host 10.0.2.0/24 and host 10.0.3.0/24Use curl to probe service availability across segments:
# Check if a service in the database zone is reachable from the internal zone
curl -v --connect-timeout 5 \
http://10.0.4.100:8080/health \
--resolve "db.example.com:80:10.0.4.100"Check firewall state with nft:
# List all active connections in the firewall
nft list chain inet firewall forwardSharp edge: A service in the internal zone reports high latency when accessing the database, but ping and traceroute show no packet loss. The issue is that the service uses a load balancer with session affinity (sticky sessions), but the load balancer does not maintain state across failover. The solution is to enable session persistence and to verify that the load balancer updates its session table after a failover.
Ensure that services can communicate across segments with consistent naming and discovery.
Use DNS to map service names to VIPs:
payment-service.example.com. IN A 10.0.4.100
analytics-service.example.com. IN A 10.11.0.200Use service discovery protocols like mDNS or DNS-SD:
# Resolve a service using DNS-SD
avahi-resolve-service payment-service _http._tcp example.com 10.0.4.100Silent failure: A service in the staging environment cannot resolve payment-service.example.com even though the DNS entry is correct. The root cause is that the DNS resolver uses a different TTL than expected. The service queries the DNS server every 30 seconds, but the DNS record has a TTL of 1 hour. As a result, a new version of the payment service is deployed, but old clients continue using the old IP address.
Sharp edge: DNS TTL and service mesh cache coexist but may conflict. A service mesh caches service discovery results for 10 seconds, but DNS has a TTL of 60 seconds. When a new database node is added, the service mesh updates its local cache, but DNS updates take longer. The result is a brief period of inconsistent routing.
Network segmentation is not just about dividing networks—it is about defining trust, performance, and resilience boundaries. The patterns described here—zone-based, security-based, service-specific, overlay-based, and application-level—form the foundation of scalable, secure, and observable distributed systems. Each pattern has subtle failure modes and configuration traps that only emerge under load or after a network event. Mastering these patterns enables engineers to build networks that are not only correct but also self-healing and predictable.
This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy