Contractors must reach internal applications from hotel and customer networks that block all outbound traffic except HTTPS on TCP port 443, and IPsec clients fail to connect from those networks. Which remote access approach fits this constraint?
Select an answer to reveal the explanation.
Short Explanation
If the only door open is the HTTPS door, you walk in through it. An SSL/TLS VPN rides TCP 443, so it looks like normal web traffic to the hotel firewall. The trap is NAT-T; UDP 4500 is still a port that strict networks block.
Full Explanation
An SSL or TLS remote access VPN establishes its tunnel over TCP 443, the same port used for HTTPS, so it passes through networks that permit only web traffic. Cisco Secure Client can connect to Cisco Secure Firewall using TLS, and it can also try DTLS over UDP for better performance, falling back to TLS when UDP is blocked. The constraint in this case is a filtering policy, which makes TLS-based transport the right choice. IKEv2 with NAT Traversal uses UDP 500 and UDP 4500; NAT-T solves address translation, not port filtering, and a network that allows only TCP 443 drops both ports. GETVPN is designed for site-to-site encryption across private WANs with a key server and group members, not for individual laptops on hotel networks. Site-to-site IPsec from a laptop is not a remote access design, and IKE runs before any ESP tunnel exists, so it cannot hide inside ESP; it would still need UDP 500 or 4500 and protocol 50. Exam caveat: Cisco Secure Client can use IPsec IKEv2 or TLS on the same head-end, so connection profiles should offer TLS where clients face restrictive networks. Operational check: test a connection from a network that permits only TCP 443 and confirm the session establishes, noting whether DTLS is in use or the client fell back to TLS.