Why Your Network Switch Has Amnesia

Welcome to part 3 of our IT/OT Series (IOS), where we take our open Layer 3 routing fabric and lock it down into a secure, segmented Zero-Trust environment.

Dark Network Cabinet. Source & Credits: https://www.pexels.com/photo/network-rack-17323801/

In Part 2 of this series, we wiped a core Cisco SF300–24P multilayer switch, survived a full control plane crash, and successfully proved hardware-level Inter-VLAN routing. But there was a major security flaw: the network was entirely open. Any device on the Home network could talk to the Work network, and vice versa.

In a hybrid enterprise environment, leaving your routing fabric wide open is an invitation for disaster. We needed to implement a Unidirectional Isolation Policy — a rule architecture where our Trusted Home network (VLAN 10) can monitor and initiate traffic to the Untrusted Work network (VLAN 20), but the Work network is strictly prohibited from initiating any inbound connections back.

To achieve this, we had to dive into Access Control Lists (ACLs), survive a Windows kernel routing conflict, and navigate the dangerous trap of stateless filtering.

Click here to access the full build guide.

Part 1: Architecture and the Routing Metric Trap

Our first step was to define the security boundary. We created an IPv4-Based Access Control List named isolate-work directly inside the Cisco switch control plane.

Instantiating the isolate-work ACL container in the switch control plane to house our restrictive rules.

With the container ready, our initial connectivity tests immediately threw a wall of Request Timed Out (RTO) errors. Before we could even test our security rules, we ran into a classic host operating system quirk: a Routing Metric Conflict.

The Windows kernel was quietly prioritizing my active Wi-Fi interface (using its default gateway metric) over the physical Ethernet cable plugged straight into the Cisco switch. Because the OS was routing packets out of the wrong adapter, traffic never even made it to the switch hardware.

The fix? Manually disabling the Wi-Fi adapter on the host machine. This forced the Windows kernel to respect the switch’s Switch Virtual Interface (192.168.10.1) as the absolute, non-negotiable gateway, instantly restoring traffic flow to the Cisco ASIC (Application-Specific Integrated Circuit—the specialized microchip that handles wire-speed packet processing).

Part 2: The Stateless ACL Trap (The Smoking Gun)

With baseline routing restored, we provisioned our first rule: an Access Control Entry (ACE) designed to deny ICMP Type 8 (Echo Request / standard ping initiation) traffic originating from the untrusted 192.168.20.0/24 subnet.

Defining the ACE rule: Priority 10, Action: Deny, Protocol: ICMP, Type: Echo Request, targeting the untrusted work subnet.

We bound this rule to the ingress port (FE24), expecting a clean security boundary. Instead, all bidirectional traffic instantly died. Even our trusted laptop couldn't ping across the network anymore.

This exposed a critical engineering concept: Stateless vs. Stateful filtering.

Unlike a stateful firewall (such as Windows Defender or an industrial Siemens SCALANCE firewall), which remembers connection states and automatically allows return traffic back through, a Cisco ACL is completely stateless. It looks at every single packet in total isolation.

During the port binding phase, the interface had accidentally been configured with a default action of “Deny Any.”

Here is what went down: When our trusted laptop (VLAN 10) pinged the untrusted laptop (VLAN 20), the work laptop successfully generated an Echo Reply. But when that legitimate reply hit ingress port FE24, the switch evaluated it. Because the return packet didn't explicitly match a "Permit" rule, it fell back to the default action: Deny. The switch ASIC mercilessly blackholed our return traffic.

Remediating the trap by switching the interface binding default action to “Permit Any” while keeping the specific ICMP deny rule active.

To fix this, we altered the Port Binding Default Action to “Permit Any.” This transformed our ruleset into a surgical strike: it drops unauthorized connection attempts from the work network, while safely allowing legitimate, asymmetric return traffic to cross back over.

Part 3: Deep Packet Forensics (Hex Dump Validation)

With the policy successfully remediated, it was time to verify what was happening on the physical wire using Wireshark packet captures.

Wireshark packet capture validating successful ICMP Type 0 replies versus hardware-generated Destination Unreachable drops.

The forensics proved our Zero-Trust architecture was holding up at wire speed:

• Trusted to Untrusted (Success): When our Home laptop sent an ICMP Type 8 request, the switch routed it through. The Work laptop replied with an ICMP Type 0 (00 00) Echo Reply. Because our ACL default action was set to permit, the ASIC smoothly routed the packet back home.
• Untrusted to Trusted (Blocked): When the Work laptop tried to initiate a ping back into our network, it sent an ICMP Type 8 request. The packet hit port FE24, matched our Priority 10 deny rule, and was dropped instantly at Layer 3. The switch gateway (192.168.10.1) fired back an ICMP Type 3 Code 0 (03 00 - Destination Unreachable) message, explicitly telling the host that the path was administratively blocked by hardware.

Conclusion

We took an open routing fabric and successfully transformed it into a segmented, unidirectional Zero-Trust boundary using stateless ASIC-level filtering. By diagnosing host OS routing conflicts and navigating the hidden traps of stateless ACL default actions, we locked down the ingress ports without breaking legitimate return traffic.

But securing network traffic using basic IP rules is only scratching the surface. In Part 4 of our IT/OT Infrastructure series, we are going to deploy an Anti-Spoofing Fabric, combining DHCP Snooping, Dynamic ARP Inspection (DAI), and IP Source Guard to block rogue endpoints and MAC spoofing at wire speed. Stay tuned.

Author’s Note: This article is part of an ongoing Enterprise IT/OT Infrastructure Security Lab series, demonstrating practical engineering concepts for securing complex hybrid environments.