Network Segmentation Testing

Case Study: Network Segmentation Testing

Operational networks often need carefully controlled access to cloud-management platforms, remote-support services and the public Internet while remaining isolated from the wider enterprise. A boundary that appears correct in a diagram must still be challenged from the perspective of a device connected inside the segment.

This case study outlines a ProCheckUp network segmentation assessment of a live passenger-processing environment operated by an international transportation provider. The engagement combined authorised local-network access, sampled cross-zone testing, VLAN-challenge techniques, passive protocol analysis, firewall validation and targeted switch-and-firewall configuration review.

Overview

An international transportation provider commissioned ProCheckUp to determine whether a dedicated operational subnet genuinely stopped at its intended trust boundary. The network supported a live passenger-processing service and was expected to communicate only with approved cloud-management, remote-access, DNS and Internet destinations.

Testing began from an authorised connection within the operational subnet. ProCheckUp assessed whether a connected device could identify local infrastructure, escape its allocated VLAN, reach sampled internal networks, use unauthorised DNS resolvers or exploit weaknesses in the access-switch and firewall configuration.

The principal result was positive: unauthorised internal networks could not be reached, VLAN double-tagging did not provide access to another network, the assessed port remained limited to its assigned segment and firewall rules constrained traffic to explicit ports. The review nevertheless identified ten findings: one High, two Medium, five Low and two Informational.

Engagement at a glance

• - Live operational subnet supporting a passenger-facing service
• - Approved cloud-management, remote-access, DNS and Internet routes considered
• - Authorised connected-device and local-insider perspective
• - Access-switch, VLAN, firewall, DNS, IPv6 and discovery controls assessed
• - Sampled reachability testing against prohibited internal zones
• - Targeted configuration review correlated with observed network behaviour
• - Zero unauthorised internal networks reached during the completed assessment

Challenge

Network segmentation assurance in a live transport environment had to produce meaningful evidence without interrupting passenger operations. The engagement therefore balanced realistic attacker behaviour with strict non-disruption limits.

Operational availability

Several spanning-tree and protocol-abuse techniques can disable a switch port or affect connected services. Deliberate denial-of-service testing was prohibited, so the assessment evaluated those risks through configuration evidence and non-disruptive validation rather than operational exploitation.

Deceptive scan behaviour

Firewall flood and reconnaissance protections caused scans to report large numbers of apparently open ports while connection attempts returned no usable services. This materially extended scan time, but it also demonstrated an effective anti-enumeration control.

Partial configuration visibility

The switch and firewall were reviewed through a targeted screen share rather than a complete configuration export. Conclusions were therefore limited to the controls relevant to the operational service and the behaviour directly observed during testing.

Shared operational dependencies

The subnet depended on approved external services and infrastructure managed across more than one operational owner. Hardening changes therefore needed to preserve the intended service path while reducing unnecessary trust and configuration ambiguity.

Assessment Scope

The public case study generalises all original technical identifiers. Testing concentrated on the following trust boundaries:

• - Operational endpoint context: the traffic and external dependencies required by the passenger-processing service
• - Access switching: port admission, device restrictions, software lifecycle, spanning-tree protection and isolation controls
• - VLAN boundary: native-VLAN configuration, assigned network behaviour and attempts to escape through tagging techniques
• - Firewall enforcement: permitted ports, application definitions, reconnaissance protection, packet-drop and buffer-protection settings
• - Cross-zone reachability: sampled routes towards internal networks that were not authorised for the operational service
• - Network protocols: IPv6 handling, external DNS use and link-layer information visible to a connected device
• - Configuration evidence: targeted switch and firewall settings relevant to the tested service route

Potentially disruptive protocol attacks were excluded. Remote-network testing used a representative sample and was time-limited by anti-enumeration behaviour. The wider enterprise configuration and the approved cloud-management and remote-access platforms themselves were outside the completed assessment.

Solution

ProCheckUp combined direct network testing with manual configuration correlation. The objective was not only to identify settings, but to establish which routes actually worked, which failed and why.

The assessment followed four stages:

• 1. Define: document the assigned operational subnet, approved external destinations, prohibited internal zones and non-disruption constraints.
• 2. Connect: use an authorised test device on the operational port to observe addressing, passive protocols, services and local trust assumptions.
• 3. Challenge: test sampled cross-zone reachability, VLAN escape, scanning, DNS paths and defensive responses without performing prohibited disruption.
• 4. Correlate: compare observed behaviour with targeted switch and firewall settings, then separate confirmed controls from hardening opportunities.

Three evidence states were kept distinct. A confirmed control showed that an unauthorised route failed. An observed weakness showed that a configuration or protocol exposed unnecessary capability. A potential consequence described what might occur only if physical access and additional exploit conditions were combined.

Finding scores are presented using the CVSS version 2 values recorded in the source assessment.

Findings Identified

The ten findings refined a boundary that was already broadly effective.

Outdated switch software — High, CVSS 8.6

The software version observed during configuration review was behind the then-current release and associated with known denial-of-service and command-injection exposure. Lifecycle debt on a network device protecting a live operational service increased the consequences of future compromise or instability.

Recommendation: upgrade the managed switch through a controlled maintenance process, include core network equipment in formal patch governance and validate normal service operation after change.

Open device-admission policy — Medium

The assessed access port did not restrict connecting hardware addresses. A person who obtained physical access could attach an unknown device and begin local reconnaissance even though the wider segmentation boundary remained effective.

Recommendation: implement hardware-address restrictions, sticky controls or identity-based admission such as 802.1X where operationally feasible; limit devices per port and alert on unexpected link or identity changes.

Default native VLAN retained — Medium, CVSS 4.3

The default VLAN was retained as the native VLAN for an operational integration. VLAN hopping was not achieved during testing, but using the default untagged VLAN created avoidable design exposure and reduced configuration clarity.

Recommendation: migrate untagged traffic to a dedicated non-default VLAN, coordinate the change with all infrastructure owners and repeat service-route and segmentation validation afterwards.

BPDU Guard denial-of-service trade-off — Low, CVSS 3.1

BPDU Guard was correctly enabled and would block unwanted spanning-tree traffic. If a person first gained access to the port, deliberately triggering the control could potentially disable the port and affect availability.

Recommendation: retain BPDU Guard, reduce the chance of abuse through stronger device admission and test recovery procedures during an approved maintenance window.

Broad firewall application matching — Low, CVSS 3.1

Firewall policy restricted traffic to specific ports effectively, but the application definition used a broad matching condition rather than the most precise approved service set.

Recommendation: define the exact applications required by the operational service, retain explicit port restrictions and monitor rule usage before and after refinement.

Incomplete IPv6 drop rules — Low, CVSS 3.1

Several IPv6 drop controls were active, but not all relevant traffic was comprehensively denied. The operational service was not understood to require IPv6.

Recommendation: drop all IPv6 where it is not operationally required, document any retained dependency and regression-test the service after change.

Link-layer network-information disclosure — Low, CVSS 3.1

Passive traffic exposed details about the gateway, switch, VLAN and management plane through standard discovery and control protocols. This information could help a person connected to the port understand the local environment more quickly.

Recommendation: reduce unnecessary discovery traffic on exposed access ports, strengthen physical and device admission controls, and monitor for passive or active reconnaissance at the network edge.

Direct use of approved external DNS — Low, CVSS 3.1

DNS egress was highly restricted and only approved resolver addresses worked. Direct external resolution nevertheless preserved a limited route that could be reduced further through an internal or firewall-hosted resolver.

Recommendation: consider controlled internal DNS proxying, restrict resolver destinations explicitly and use encrypted DNS only where supported by the operational architecture.

Additional defence-in-depth opportunities — Informational

Port isolation, packet-buffer protection, granular packet drops and protocol-protection exclusions were not fully enabled for the operational zone.

Recommendation: review each option against availability requirements, introduce suitable controls through staged maintenance and regression-test expected passenger-processing traffic.

Effective firewall scan deception — Informational

Remote scans misleadingly showed large numbers of open ports, but connection attempts returned no usable services. Flood and reconnaissance protection materially slowed host and service discovery.

Recommendation: no control change was required. Future test plans should allow additional time and may use agreed known-active hosts to improve scan calibration.

Segmentation Boundary Validation

The central objective of the engagement was achieved: testing did not identify a route from the operational subnet into unauthorised internal networks.

Controls confirmed during testing

• - The connected port remained limited to its assigned operational network
• - VLAN double-tagging did not provide access to another network
• - Sampled unauthorised internal zones could not be meaningfully reached
• - Firewall rules restricted the operational service to explicit ports
• - Unauthorised DNS resolver destinations were blocked
• - Reconnaissance protection obscured real hosts and services

Residual conditions that still mattered

• - An unknown device could connect to the access port if physical access were obtained
• - Passive protocols exposed useful local-network metadata
• - The managed switch required urgent lifecycle remediation
• - Default-VLAN design and broad application matching reduced policy precision
• - Unused IPv6 and optional defence-in-depth settings remained available
• - Live-service constraints prevented selected disruptive-resilience tests

A successful segmentation result is not a reason to ignore local weaknesses. Port admission, device lifecycle and configuration drift can gradually erode a boundary that currently works.

Authorised Risk Model

The following sequence explains how the observed conditions could combine, while preserving the distinction between confirmed evidence and potential impact:

• 1. Physical port access — assumed threat condition: an unauthorised person or maintainer obtains access to a live operational connection.
• 2. Unknown device association — confirmed test condition: the port does not enforce a hardware-address restriction before permitting local connectivity.
• 3. Local reconnaissance — confirmed: passive protocols and scanning reveal gateway, switching, VLAN and service information.
• 4. Segmentation challenge — confirmed: sampled cross-zone routes, DNS paths and VLAN escape techniques are exercised.
• 5. Enterprise route blocked — confirmed: unauthorised networks are not reached and double-tagging does not escape the assigned zone.
• 6. Local control exploitation — potential: outdated switching software or configuration weaknesses could become relevant if an additional exploit condition existed.
• 7. Service disruption or wider pivot — potential: further impact would require conditions not demonstrated in the authorised assessment.

This is an authorised risk model, not evidence of a completed real-world compromise. The route into the wider enterprise failed during the completed test, and disruptive exploitation was intentionally not performed.

Control Effectiveness and Assessment Boundaries

Positive controls observed

• - Unapproved internal networks were not reachable
• - The operational port remained constrained to its assigned network
• - VLAN double-tagging did not succeed
• - Specific firewall ports and approved DNS destinations were enforced
• - BPDU Guard provided spanning-tree protection
• - Firewall scan deception materially hindered enumeration

Limitations requiring follow-up

• - Denial-of-service and other potentially disruptive protocol attacks were prohibited
• - Remote-network testing used a sample rather than every enterprise subnet
• - Only targeted switch and firewall settings were reviewed through screen share
• - The full configurations and wider infrastructure architecture were not assessed
• - The approved cloud-management and remote-access platforms were outside scope
• - The source material does not confirm that recommendations were later implemented or independently retested

The completed evidence supports the conclusion that the intended segmentation boundary held under the tested conditions. It does not establish resilience against every possible denial-of-service technique, future configuration change or vulnerability that may arise after the assessment.

Outcome

The engagement converted a binary “is it segmented?” question into a layered view of reachability, local exposure, configuration precision and operational resilience.

The customer received evidence that its passenger-processing network could not reach the sampled unauthorised enterprise zones and that common VLAN escape attempts were ineffective. This allowed remediation to focus on the controls most likely to erode the boundary over time rather than redesigning a separation model that was already broadly effective.

Infrastructure, security, operations and third-party owners were given a shared triage order: patch the switch, control which devices can connect, remove default-VLAN dependency, refine firewall policy, complete IPv6 handling and assess additional defence-in-depth during safe maintenance windows.

The case study also preserves important distinctions: the scan-deception control was recognised as effective, BPDU Guard was retained despite its availability trade-off, and the absence of a demonstrated cross-network compromise was stated explicitly.

Publication boundary: this case study does not state that the complete remediation programme was subsequently implemented or independently retested.

Remediation Priorities

Immediate lifecycle and exposure reduction

• - Upgrade the managed switch to a supported and tested software release
• - Confirm that switches, firewalls and other core devices are included in patch governance
• - Review administrative accounts, logs and configuration for unexpected change
• - Plan the upgrade around operational availability and rollback requirements

Engineering hardening

• - Implement hardware-address restrictions, sticky controls or 802.1X where feasible
• - Limit devices per port and alert on unknown link or identity changes
• - Replace the default native VLAN with a dedicated non-default design
• - Refine firewall application definitions while preserving explicit port restrictions
• - Drop unused IPv6 and document any retained dependency
• - Consider internal DNS proxying, port isolation and packet-buffer protection
• - Test BPDU Guard recovery and other disruptive-resilience scenarios out of hours

Sustained segmentation assurance

• - Maintain approved-route and prohibited-zone documentation
• - Monitor firewall, VLAN and access-port configuration drift
• - Retest after switch, firewall, third-party integration or service-architecture changes
• - Review operational dependencies with all infrastructure owners
• - Repeat representative connected-device testing at defined intervals

The Core Security Lesson

Segmentation is proven by the route that fails.

Separate VLAN names and firewall diagrams are not sufficient evidence. Strong assurance requires a verified connected-device identity, current network software, explicit routing and application policy, controlled protocols and direct proof that the operational subnet cannot cross its intended trust boundary.

The correct question is not simply:

“Are these systems on a separate VLAN?”

It is:

“From this connected device, which routes actually succeed, and which are demonstrably blocked?”

How ProCheckUp Helps

ProCheckUp’s Network Segmentation Testing service validates the relationship between connected devices, local switching, VLAN design, firewall policy and the routes protecting sensitive or operational systems. Support can include:

• - Internal and operational-network reachability testing
• - VLAN and trust-boundary validation
• - Access-port, device-admission and 802.1X assessment
• - Firewall rule and application-policy verification
• - Switch and firewall configuration review
• - IPv4, IPv6, DNS and network-discovery analysis
• - Third-party and cloud-route boundary testing
• - Non-disruptive live-environment testing plans
• - Out-of-hours resilience and denial-of-service assessment where authorised
• - Prioritised remediation and post-change verification

Related services include Infrastructure Testing, Build and Configuration Reviews and Penetration Testing.

Conclusion

This engagement demonstrated the value of testing network segmentation from inside the protected zone. The customer’s principal boundary held: the operational service could use its approved routes, while sampled unauthorised enterprise networks remained inaccessible.

The remaining risks were concentrated at the local entry point and control plane—outdated switch software, open device admission, default-VLAN use, broad firewall definitions, incomplete IPv6 handling and optional defence-in-depth settings. Addressing those weaknesses helps ensure that physical access, lifecycle debt or future configuration drift do not turn a currently effective boundary into a wider compromise path.

To discuss an operational-network segmentation assessment, firewall and switch configuration review or wider infrastructure penetration test, contact ProCheckUp.