A bank places WAN Edges behind a stateful firewall with NAT to reach hosted Controllers over the Internet. Control connections intermittently fail during initial bring-up, while user data sessions work after establishment. Which firewall and NAT handling allows DTLS/TLS control connections to form reliably?
Select an answer to reveal the explanation.
Short Explanation
Your edges must call out to build trust, so let those calls through. Allowing outbound control sessions with return traffic keeps DTLS/TLS handshakes alive through NAT. It's like letting staff badge out so security will let them back in.
Full Explanation
Reliable formation succeeds because hosted discovery first requires outbound UDP DTLS to the Validator for authentication and certificate exchange, followed by DTLS or TLS to the Controllers and Manager for persistent control, with the stateful firewall allowing the matching return sessions so NAT bindings stay intact during bring-up, explaining why data works later while initial control flaps. The private-MPLS Validator approach fails on reachability because when Controllers are hosted over the Internet the Validator is also Internet-reachable and must pass the same Internet firewall, so forcing it private breaks authentication. The local-console Manager approach fails on completeness because the Manager needs the same DTLS/TLS reachability for centralized management, templates, and certificate operations, leaving bring-up incomplete. The TCP-only Controller approach fails on protocol flexibility because control can form over UDP DTLS or TCP TLS for traversal, so permitting only TCP TLS removes a required path and causes intermittent failure when DTLS is used. Exam caveat: separate initial Validator contact from persistent Controller connections and remember the Manager is explicitly required. Practical check: verify outbound UDP 12346 for DTLS and TCP 23456 for TLS with offsets for extra controllers, confirm NAT preserves ports with return allowed, and review drops during bring-up.