Executive Summary
Users at Acme Manufacturing experienced severe and inconsistent delays when accessing HTTPS websites. Pages would appear to stall for up to several minutes before loading, despite normal DNS resolution and successful TCP connections.
After packet-level analysis confirmed TLS handshake timeouts caused by inline inspection delays, a third-party firewall was temporarily installed and immediately resolved the issue. Reintroducing a new Meraki firewall reproduced the problem, confirming the root cause was not hardware failure, but client tracking behavior tied to network architecture.
The issue was permanently resolved by implementing a network split that allowed Meraki to track clients by IP address instead of MAC address.
Business Impact
Intermittent loss of access to critical external websites
Productivity disruptions across multiple departments
Reduced confidence in network reliability
Difficult-to-diagnose issue that evaded traditional monitoring tools
Because HTTPS is foundational to modern SaaS and cloud platforms, the issue represented a systemic operational risk.
Initial Findings
Packet capture analysis of multiple unrelated HTTPS destinations revealed the same failure pattern:
After extended retransmissions, a new connection attempt would succeed instantly. The identical behavior across different external servers confirmed the problem originated inside the client's network, not on the internet or destination servers.
Validation via Third-Party Firewall
To isolate the issue, a third-party firewall was installed and configured with equivalent security policies.
Result:
All HTTPS connections worked immediately and consistently.
This step was critical. It demonstrated that:
- The ISP and upstream network path were not at fault
- Client devices were not misconfigured
- The issue was specific to how traffic was being processed by the original firewall platform
Why the New Meraki Firewall Still Failed
A new Cisco Meraki firewall was installed to rule out hardware or firmware corruption. However, once the device downloaded its configuration from the cloud, the issue immediately returned.
This confirmed the root cause was configuration and architecture, not a defective appliance.
Root Cause: Meraki Client Tracking by MAC Address
Further analysis revealed a key architectural detail:
- •The Meraki firewall was configured to track clients by MAC address
- •The network included downstream switches and routed segments
- •From the firewall's perspective, multiple clients appeared to originate from the same MAC address
This caused the firewall to intermittently lose or misassociate TCP/TLS connection state during inspection, particularly during the TLS handshake phase. As a result, return traffic (Server Hello packets) was delayed or dropped while inspection processes waited or timed out.
This behavior aligns with known limitations of MAC-based client tracking in routed or mixed network topologies.
The Architectural Fix: Network Split & IP-Based Tracking
Because Meraki requires different handling for wired versus wireless clients, the permanent fix involved implementing what Cisco Meraki refers to as a network split.
What Changed
- Wireless traffic was segmented separately from wired traffic
- Wired clients were routed in a way that allowed IP-based client tracking
- Meraki was able to correctly associate sessions with individual client IPs instead of shared MAC addresses
Once client tracking switched to IP-based behavior, TLS inspection completed normally and connection state was maintained correctly.
Final Outcome
The resolution was architectural, not a workaround, and remains stable under normal and peak traffic conditions.
Key Takeaways
TLS handshake delays are often inspection state issues, not bandwidth or DNS problems
Successfully testing with a different firewall is a powerful diagnostic step
Client tracking mode (MAC vs IP) matters in modern routed networks
Proper network segmentation is essential for reliable encrypted traffic inspection
Services Delivered
Conclusion
Modern security platforms are powerful, but their behavior is highly dependent on network design. When client tracking mechanisms do not align with topology, encrypted traffic can fail in ways that appear random and difficult to diagnose.
This case underscores the importance of architectural awareness, not just configuration, when deploying next-generation firewalls.
Experiencing Similar Network Issues?
Our team specializes in diagnosing and resolving complex firewall and network issues. Let us help you build a more reliable infrastructure.
Get a Consultation