Segmented Plant Network Deployment with Partial Backup Failures
A manufacturer is deploying PPDM into a regulated plant network. The PPDM appliance sits in a management VLAN; the DD6300 sits in a backup VLAN; ESXi hosts and vCenter sit in a server VLAN. Firewalls between zones are default-deny, and change control takes two weeks per rule. DNS has forward and reverse records for PPDM and DD, but NTP is blocked from the management VLAN. Installation completes, the UI is reachable from the admin jump host, and vCenter registration succeeds. Asset discovery finds VMs, but backups fail at 90% and vProxy registration intermittently times out. The team has one maintenance window before go-live and cannot open all ports. They ask which flows are required for control and data, how to prove the failing flow, and what temporary design reduces firewall changes without violating segmentation.
1. Separate the required control and data flows and identify the most likely gap.
Read the worked answer
Control flows include the admin jump host to PPDM on 443, PPDM to vCenter on 443, PPDM to ESXi on 443, PPDM to DD management on 443, and PPDM to DNS and NTP. Data flows include vProxy to ESXi for VM data and vProxy to DD Boost on 2052. Because the UI, vCenter registration, and discovery work, most control paths are open. A failure at 90% usually occurs when data transfer starts after the snapshot, so suspect vProxy-to-DD Boost or vProxy-to-ESXi data. Intermittent vProxy registration points to a control flow or DNS/time issue. Do not open all ports; use the support matrix and firewall logs to test each required flow.
2. Describe how to prove the failing flow with evidence from the appliance, firewall, and DD.
Read the worked answer
Reproduce with a small VM. From the vProxy, test TCP 2052 to the DD and TCP 443 to vCenter and ESXi using nc or a TLS client. Check firewall logs for denies from the vProxy IP to the DD IP on 2052 and from the vProxy to ESXi. Validate DD Boost credentials, storage unit, and interface selection. At 90%, the snapshot may have succeeded while the data path failed, so correlate PPDM job details, vProxy logs, DD events, and packet captures on both sides. For intermittent registration, check DNS forward and reverse lookup and NTP offset. Present timestamps and a single failed flow, not a general port list, to change control.
3. Propose a temporary segmented design that minimizes firewall changes without collapsing zones.
Read the worked answer
Place a vProxy in the backup VLAN next to the DD so vProxy-to-DD Boost stays inside one zone, and allow only the vProxy-to-ESXi data flow plus PPDM control flows. This reduces cross-zone rules and keeps backup data off the management VLAN. Do not move PPDM into the backup VLAN unless management access, AD, DNS, and NTP are permitted there. Fix NTP first; time skew can break authentication and certificates and cause intermittent registration. Use temporary rules with an expiry date and ticket, not any-any. Validate with a canary backup and restore, then remove temporary rules and record the final flow matrix.