Network segmentation acceptance testing: proving allowed and forbidden paths

An infrastructure security assessment should answer a more precise question than “is the network segmented?” It should show whether each important source can or cannot start a defined connection to a defined destination, through the path that production actually uses. That requires separate treatment of IPv4 and IPv6, new and established flows, direct and proxied paths, and network denial versus service or application failure.

Here, IPv4 and IPv6 are separate address families that can follow different routes and filters. A stateful control remembers a flow and may permit return traffic without evaluating it as a new connection. Those properties matter because a successful IPv4 denial says nothing about IPv6, and a surviving session after a rule change may say more about connection state than about the current rule for new sessions.

This is an acceptance-evidence method, not a scanning recipe. It uses designated test clients and synthetic listeners, written authorization, bounded traffic, and a matrix agreed with system owners. For a broader assessment lifecycle, see the infrastructure penetration testing methodology; the focus here is the narrower proof that segmentation decisions work on actual paths.

A segmentation claim must name both endpoints

“Users cannot reach production” is not testable enough. A defensible claim names the source zone, source workload or user identity, source interface, address family, destination service, transport protocol, initiation direction, intermediate path, and expected allow or deny decision. If any of those changes, the claim may change.

Identity belongs in the statement even when the firewall matches only addresses. A laptop on a user VLAN, a backup agent on the same subnet, and an administrator using a managed jump host may have different permissions. Network reachability and resource authorization are separate controls: an allowed TCP path can still end in an authentication denial, while an identity-aware proxy can provide approved application access without creating direct network reachability.

Define the business purpose as well. “Backup server may reach the database” should become “the named backup agent may initiate TLS to the designated backup endpoint during its window; interactive administration and direct database client access remain denied.” That wording creates rows that can be tested and reviewed instead of a vague zone-level promise.

Build an endpoint-pair acceptance matrix

The matrix is the core scope and later becomes the result register. Each row is one assertion. Grouping hundreds of systems into representative classes is acceptable only when the shared routing, policy objects, endpoint controls, and ownership are demonstrated. A representative result should not silently cover an untested exception.

The rows below are examples of how to specify tests, not observed results. Synthetic names make that boundary explicit.

Record a unique test ID, owner, window, rule or policy object, and evidence location for every row. The expected result must be frozen before execution; otherwise an unexpected allow can be relabeled as intended after the fact.

Resolve the path and the identity seen by each control

Start with read-only evidence: route tables, effective firewall or cloud policy, security-group or network-security-group associations, proxy configuration, load-balancer listeners, NAT rules, DNS records, host firewalls, and recent change records. Draw the enforcement points in order. The decision at the source host, subnet edge, cloud control, transit appliance, proxy, and destination host may differ.

NAT and proxies change what downstream controls can identify. An inbound cloud filter can evaluate a private address after destination translation; an outbound control can act before source translation. A forward proxy may originate a new connection under its own address while carrying user or workload identity at the application layer. In AWS, a path routed through a middlebox can require peer private addresses or CIDRs where a security-group reference alone would not establish the intended path. These are product and topology details, so evidence should state the tuple and identity seen at each hop rather than assuming the original client remains visible.

Approved conduits deserve explicit treatment. A management portal, bastion, backup proxy, or deployment broker may legitimately bridge zones while direct routing remains denied. The hybrid-cloud security audit guide explains the wider trust-boundary problem; in this matrix, represent the direct path and the mediated path as separate rows with different expected results.

Use a five-step evidence method

Every active check should be authorized in writing. Name the client, listener, addresses, ports, protocol, packet or request limit, test window, monitoring owner, stop conditions, evidence retention, and people allowed to change a rule. Use synthetic services and data. Do not discover targets by scanning; exercise only listed pairs.

1. Definefreeze endpoint-pair claims, expected decisions, owners, and exceptions
2. Collectexport read-only routes, effective policies, translations, DNS, and host controls
3. Preparevalidate designated clients, synthetic listeners, timestamps, and positive controls
4. Exerciserun bounded allow and deny checks for each family, direction, and connection state
5. Correlatejoin source, enforcement, and destination evidence; classify and schedule retest

A positive control is part of the test, not an optional convenience. If a deny row targets a synthetic listener, prove that the listener is healthy from an authorized source using the same address family and protocol. Confirm time synchronization and use a unique marker so source, policy, proxy, and destination events can be joined without inspecting business data.

For an allowed row, verify the intended service response and the expected control decision. For a denied row, send the smallest agreed connection attempt and look for the expected enforcement evidence. Repetition should be just enough to rule out transient loss within the agreed bound, not a sweep of ports or hosts.

Classify outcomes without guessing

A TCP timeout does not prove a firewall block. It can result from no route, silent host filtering, an unhealthy listener, asymmetric routing, packet loss, a stale DNS answer, or a control that deliberately drops traffic. Classify a row only after correlating at least the source with either the destination or the relevant enforcement point; the strongest cases include all three.

Use five final statuses:

• Allowed: the intended new connection crossed the expected path and the destination or approved intermediary produced the intended effect.
• Blocked: the designated enforcement point recorded the expected deny, the destination saw no prohibited initiation, and the positive control proved the target and collection path were healthy.
• Unreachable: routing, neighbor discovery, name resolution, or another prerequisite prevented the test from reaching the policy decision being assessed.
• Unknown: evidence is missing, inconsistent, or too weak to attribute the result. A timeout with no matching control or destination evidence belongs here.
• Exception: access occurred through a documented conduit or temporary rule with an owner, purpose, expiry, and compensating controls. This is not automatically a pass: record policy conformance separately. An undocumented bypass is a finding.

Keep the immediate effect separate from the status and establish who produced it. A TCP reset can come from a closed destination service or an intermediary configured to reject. A DNS failure means the named path was not exercised. A confirmed destination response such as 401, 403, failed SSH login, or a rejected client certificate proves reachability to that responding endpoint followed by an application or TLS-layer rejection. A response generated by a proxy does not prove that the private backend was reached.

Test new and established flows separately

Stateful controls distinguish a newly initiated flow from return traffic or an already tracked connection. Therefore each material rule-change scenario needs two probes: attempt a fresh connection after the change, and observe an existing authorized session under a pre-agreed, harmless protocol. Record the exact control type and configuration.

Do not generalize vendor semantics. AWS documents that tracked security-group connections can continue until their tracking state expires, while some broadly permitted untracked flows can be interrupted immediately when a rule changes. Azure network security groups apply changed rules to new connections and can leave an existing flow uninterrupted. Azure Firewall, although stateful for return traffic, documents that changing a rule to deny previously allowed traffic drops relevant existing sessions. “Stateful firewall” alone therefore does not predict rule-change behavior.

Testing must not rely on a production administrator session. Use a synthetic long-lived connection with an owner watching health. If the expected control cannot safely be changed, record the configuration and vendor behavior as design evidence and leave runtime persistence unverified rather than forcing a risky proof.

Give IPv4 and IPv6 independent coverage

Dual-stack names and hosts create two policy surfaces. Resolve A and AAAA records separately, preserve the returned addresses and TTL context, and execute designated rows over each applicable family. A generic “name connected” result is insufficient because the client may have selected only one family or fallen back after failure.

For each family, record the selected address, source interface, route, policy object, host binding, test ID, client build, and event times. IPv6 may take a different gateway or avoid the NAT used by IPv4. When attribution matters, correlate the IPv6 neighbor cache, switch interface, and identity events rather than assuming one lease source explains every environment.

Parity does not mean copying an IPv4 rule mechanically. ICMPv6 is needed to establish and maintain IPv6 communications, while indiscriminate forwarding also creates risk. Test the message classes required by the local topology. The acceptance question is whether both families produce equivalent decisions for the intended service with their dependencies documented.

Cover management, backup, and reverse initiation separately

Management and backup networks often have the broadest legitimate reach, so zone labels are poor substitutes for pair-level tests. Include bastion-to-server administration, monitoring queries, backup agent-to-repository traffic, repository restore direction, hypervisor or orchestration management, DNS and time services, and emergency access. For every approved path, add a nearby forbidden control: wrong source identity, direct path instead of proxy, wrong destination class, or new initiation in the reverse direction.

Direction is about who starts the connection. A stateful firewall may allow response packets without allowing a new connection from the destination zone. Test reverse initiation as a separate row with a fresh tuple. For UDP and other protocols, define what counts as a request and expected response rather than borrowing TCP language.

An identity-aware gateway can make an application available without exposing its private listener to the user zone. Prove both assertions: the gateway path authenticates and authorizes the designated identity, and direct reachability remains denied. The same logic applies to backup and deployment brokers. This keeps a useful conduit from being mistaken for broad inter-zone access.

Report decisions, gaps, and reproducible retests

The deliverable should include the frozen matrix, path diagrams, timestamped read-only configuration snapshots, test IDs, correlated source/control/destination evidence, exceptions with owners and expiry, and a retest instruction for every failed row. A finding should name the exact endpoint pair, observed family and direction, enforcement point, observed effect, expected decision, and evidence gap. Avoid claims such as “the firewall failed” when the test only established reachability.

Evidence has a validity window. Retest affected rows after changes to routes, policy associations, proxies, DNS, host listener bindings, or connection state. Preserve configuration object IDs, policy or build versions, collection times, and the reason a sample represents a class. A conclusion covers only systems shown to share those controls.

Prioritize unauthorized paths by destination sensitivity, source population, identity constraints, conduit bypass, and whether the route enables further access. Treat unknown rows as coverage debt, not as passes. A repair is closed by repeating the same bounded row and its positive control; a screenshot of a new rule does not establish runtime behavior.

Effort and price are driven by trust paths, distinct rule sets, address families, translations and proxies, identity contexts, management and backup conduits, evidence availability, production constraints, test windows, and retest rounds. Asset count alone is a weak estimator. Teams can use the scope planner to prepare those inputs.

If the environment is small and owners can produce independent source, control, and destination evidence, an internal acceptance exercise may be enough. When the matrix crosses several administrative teams, cloud and on-premises controls, or high-impact management paths, an independent assessment can provide a defensible evidence chain. Pentest.red can scope this through its infrastructure and Active Directory testing service, with active checks limited to the authorized synthetic pairs and traffic bounds agreed for the engagement.