Networking / Advanced: policy, evidence, capacity, and resilient design / Lesson 13

Separate segmentation, policy, and address translation

Model VLANs, VRFs, packet policy, and NAT as different boundaries with different identity and state requirements.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish link segmentation, routing domains, filtering, and authentication.
Reason about policy direction and translation state using offline fixtures.

Each boundary changes a different decision

A VLAN separates a link-layer forwarding domain; a VRF separates routing and forwarding context. Neither automatically proves that two applications cannot communicate, because routing, route leaking, proxies, or shared infrastructure may reconnect them. An ACL or firewall expresses permitted traffic under a particular direction and attachment point. Authentication establishes a claimed identity through a separate mechanism. Describe these boundaries independently before calling a segment trusted. Two identical address strings in different VRFs can identify different endpoints, while two different subnets can still share an overly permissive policy.

State the packet predicate and observation point

A stateless rule evaluates the packet fields available at its enforcement point. Rule order, default action, interface direction, address family, and whether translation has already occurred all matter. The following toy predicate permits one declared TCP destination service from one documentation subnet. It is not device configuration, a complete ACL engine, or a connection-state implementation. Reviewing its explicit defaults helps expose a common mistake: granting a destination port without restricting the source or destination network can authorize a much larger population than intended.

python Evaluate a declared TCP policy offline

from ipaddress import ip_address, ip_network
clients = ip_network('192.0.2.0/24')
service = ip_address('198.51.100.20')
for destination_port in (443, 22):
    allowed = (ip_address('192.0.2.10') in clients
               and service == ip_address('198.51.100.20')
               and destination_port == 443)
    print(f'{destination_port}: {"allow" if allowed else "deny"}')

Expected output

443: allow
22: deny

The fixture assumes TCP and prints allow only for port 443. It performs address arithmetic and Boolean evaluation, not packet transmission. Return traffic, rule precedence, device parsing, and authenticated user identity are deliberately outside this small predicate.

Statefulness adds a lifecycle to policy

A stateful device can associate later packets with an allowed conversation, but the exact tracked states and timeouts depend on implementation and protocol. Asymmetric forwarding can send a reply through a device that lacks the relevant state. A successful initial packet therefore does not prove that the complete exchange will pass. Document both directions, failure paths, and how state survives or is rebuilt after replacement. Stateless and stateful controls can coexist; neither should be described as understanding the business authorization of every application request.

NAT changes tuple identity rather than authenticating a user

NAT can rewrite addresses and sometimes ports, creating a mapping between observations on different sides. Mapping behavior and filtering behavior are separate properties; a translated public address is not a verified user identity. The fixture below declares two mappings that share an outside address while retaining distinct ports. It does not allocate real ports or model timeout, collision, hairpin, or protocol-helper behavior. Correlating an incident may require time, protocol, both tuples, and routing context; logging only the shared outside address can lose the distinction between clients.

python Render synthetic translation identities

translations = {
    ('192.0.2.10', 50000): ('203.0.113.5', 40001),
    ('192.0.2.11', 50000): ('203.0.113.5', 40002),
}
for inside, outside in translations.items():
    print(f'{inside[0]}:{inside[1]} -> {outside[0]}:{outside[1]}')

Expected output

192.0.2.10:50000 -> 203.0.113.5:40001
192.0.2.11:50000 -> 203.0.113.5:40002

Both clients map to one documentation address but different ports. Dictionary insertion order makes the two output lines deterministic. These declared mappings establish no reachability, authorization, or actual translation state on any network.

Review complete permitted conversations

Build a policy matrix naming source role, destination role, protocol, service, direction, routing domain, and required authentication. Include denied examples, return behavior, IPv6 equivalents where applicable, and dependency traffic such as naming. Review route leaks and management access separately from ordinary application flows. Offline models can identify contradictory requirements and overly broad predicates, but cannot prove hardware enforcement or operational isolation. Any later implementation needs its own authorization, staged verification, observability, and rollback plan; this lesson changes no VLAN, VRF, firewall, or NAT configuration.

Common errors and fixes

A VLAN label is treated as complete isolation

Why it happens: Routing and shared dependency paths were omitted from the trust model.
How to fix it: Trace permitted crossings and apply explicit policy at the intended boundaries.
Prevent it next time: Review link, routing, management, and application trust separately.

Replies fail after a one-way policy test succeeds

Why it happens: Return direction or state ownership differs from the assumed forward path.
How to fix it: Model both directions and the state present at each enforcement point.
Prevent it next time: Include asymmetry and failover in policy acceptance cases.

A shared translated address is accepted as user identity

Why it happens: Address translation was confused with authentication and per-request authorization.
How to fix it: Use the application identity mechanism and retain necessary tuple correlation.
Prevent it next time: Document exactly what NAT logs can and cannot identify.

Check your understanding

1. Two tenants both use 192.0.2.10. Must their endpoints be identical?

Show worked solution

No. The routing-domain identity is part of the context. Separate VRFs can contain overlapping addresses, provided crossings and translation are designed deliberately. A logging key containing only the address is ambiguous; include the relevant tenant or routing domain and observation time.

2. Does allowing the forward TCP destination port fully describe a stateful exchange?