A network administrator configures a clientless SSL/TLS VPN on the corporate gateway to allow remote contractors access to internal management applications. The contractors can successfully authenticate and access internal web portals using their web browsers. However, they report being unable to connect to internal servers using native SSH desktop applications. Which of the following best explains why native SSH sessions fail in this deployment?
- Clientless SSL/TLS VPNs operate at the Application layer via a web browser and do not provide network-layer IP encapsulation or routing for standalone desktop applications.Answer
- BClientless SSL/TLS VPNs operate strictly at the Data Link layer, which prevents Layer 3 IP packet encapsulation and Layer 4 TCP port translation required by SSH clients.
- CSSL/TLS VPN tunnels only support connectionless UDP traffic, causing connection-oriented TCP applications like SSH to be blocked at the gateway.
- DThe gateway rewrites all outbound traffic headers from SSH port 22 to HTTPS port 443, causing internal SSH servers to reject the incoming packets.
Answer
Clientless SSL/TLS VPNs operate at the Application layer via a web browser and do not provide network-layer IP encapsulation or routing for standalone desktop applications.
A clientless SSL/TLS VPN relies on a standard web browser to provide remote access to web-based services (HTTP/HTTPS) operating at the Application layer. Because no virtual network adapter or client software is installed on the user host, network-layer (Layer 3) IP routing and packet encapsulation are not established. Consequently, standalone client applications such as native SSH, RDP, or FTP clients cannot send traffic through the tunnel.
Step-by-Step Solution
Key Concept
Clientless SSL/TLS VPN vs. Client-based VPN Architecture