Situation
Connectivity was required between a manufacturing PI-related environment and Azure-hosted analytics services. The environment was segmented and tightly controlled.
Manufacturing • OT / DMZ • Azure • PI / Seeq
Tracing manufacturing PI connectivity to Azure.
A sanitized case study on following the packet from the OT side through layered firewalls, DMZ relay services, NAT, and cloud routing to isolate where communication succeeded — and where return traffic needed closer scrutiny.
Three redacted cloud destinations
Packet-path validated hop by hop
Public-safe version only
What I traced
OT source, OT firewall, DMZ relay path, upstream firewall, NAT/effective egress, internet transit, cloud-side topology, and return traffic behavior.
Why it mattered
This was not just a port-opening exercise. It required proving what path the packets actually took and which security boundary shaped the outcome.
Redacted visual path
Follow the packet without giving away the farm.
The visuals below are rebuilt from the troubleshooting story — not raw screenshots. They preserve the technical shape of the problem while removing internal identifiers.
Nmap-style path map
A stylized representation of tracing the path from the manufacturing source, through security boundaries and backbone hops, toward three Azure-hosted destination groups.
- Shows the observed outbound route shape.
- Highlights layered boundaries instead of internal names.
- Keeps destination identity abstracted to endpoint groups.
Cloud-side topology
A simplified, portfolio-safe view of the Azure virtual WAN / hub perspective that helped validate cloud-side routing and supporting segments during the investigation.
- Useful for distinguishing “internet reachable” from “end-to-end working.”
- Helps explain why cloud topology review mattered.
- Makes the escalation narrative easier for non-network audiences.
Flow validation and return traffic
Outbound traffic visibility was only half the story. The critical troubleshooting step was comparing that success with what happened on the way back.
- Validated source initiation and layered outbound flow.
- Reviewed NAT and edge policy handling.
- Focused on the inbound boundary where return behavior required review.
Longer version
The public-safe story.
This case centered on connectivity between a manufacturing PI-related environment and Azure-hosted analytics resources used in a Seeq integration workflow. The environment was segmented by design: traffic originated on the OT/manufacturing side, traversed an OT firewall, crossed a DMZ relay path, passed through an upstream firewall with source translation, left through public egress, and then depended on cloud-side routing and destination reachability.
The hard part was not simply asking “is the destination reachable?” The real problem was determining how the traffic moved, which boundaries were involved, whether outbound traffic behaved as expected, and whether return traffic was treated differently on the way back. That meant comparing traceroute-style path observations, firewall policy logic, service/port requirements, and cloud-side topology context instead of stopping at a single green check.
I mapped the expected flow, validated the controlled service families required for the PI / Seeq integration path, reviewed the policy boundaries between OT, DMZ, and edge layers, and used packet-path visibility to confirm how the communication left the environment. From there, I compared that outbound success against return-path behavior to narrow the investigation to the right security boundary and produce a cleaner escalation narrative.
The result was a much clearer technical story: this was not a vague “application problem,” and it was not a mystery hidden somewhere in the internet. It was a boundary-specific connectivity problem that needed to be explained in terms of path, policy, NAT, cloud routing context, and observed return behavior. That kind of clarity is what helps cross-functional teams move from opinions to action.
What this proves
Why this belongs in the portfolio.
Cross-boundary troubleshooting
Shows the ability to reason across OT, DMZ, enterprise, internet, and cloud boundaries instead of treating them as separate universes.
Packet-path judgment
Demonstrates understanding of routing, NAT, policy, and the difference between simple reachability and end-to-end functionality.
Escalation clarity
Turns raw traces, maps, and technical observations into a story stakeholders can act on without exposing sensitive details.
Next step
Want more case studies like this?
Use this page as the model: public-safe visuals, a concise timeline summary, and a deeper technical writeup for the projects that matter most.