WatchGuard Technologies SSL VPN Operation through Firewalls and Proxies, Administration Guide

Connecting from a Private Computer

that remote users can access through the VPN connection. For more information, see “Configuring Resources for a User Group” on page 96.

All IP packets, regardless of protocol, are intercepted and transmitted over the secure link. Connections from local applications on the client computer are securely tunneled to the Firebox SSL VPN Gateway, which reestablishes the connections to the target server. Target servers view connections as originating from the local Firebox SSL VPN Gateway on the private network, thus hiding the client IP address. This is also called reverse Network Address Translation (NAT). Hiding IP addresses adds security to source loca- tions.

Locally, on the client computer, all connection-related traffic (such as SYN-ACK, PUSH, ACK, and FIN packets) is recreated by the Secure Access Client to appear from the private server.

Operation through Firewalls and Proxies

Users of Secure Access Client are sometimes located inside another organization’s firewall. NAT firewalls maintain a table that allows them to route secure packets from the Firebox SSL VPN Gateway back to the client computer. For circuit-oriented connections, the Firebox SSL VPN Gateway maintains a port- mapped, reverse NAT translation table. The reverse NAT translation table enables the Firebox SSL VPN Gateway to match connections and send packets back over the tunnel to the client with the correct port numbers so that the packets return to the correct application.

The Firebox SSL VPN Gateway tunnel is established using industry-standard connection establishment techniques such as HTTPS, Proxy HTTPS, and SOCKS. This operation makes the Firebox SSL VPN Gateway firewall accessible and allows remote computers to access private networks from behind other organi- zations’ firewalls without creating any problems.

For example, the connection can be made through an intermediate proxy, such as an HTTP proxy, by issuing a CONNECT HTTPS command to the intermediate proxy. Any credentials requested by the inter- mediate proxy are in turn obtained from the remote user (by using single sign-on information or by requesting the information from the remote user) and presented to the intermediate proxy server. When the HTTPS session is established, the payload of the session is encrypted and carries secure pack- ets to the Firebox SSL VPN Gateway.

Terminating the Secure Tunnel and Returning Packets to the Client

The Firebox SSL VPN Gateway terminates the SSL tunnel and accepts any incoming packets destined for the private network. If the packets meet the authorization and access control criteria, the Firebox SSL VPN Gateway regenerates the packet IP headers so that they appear to originate from the Firebox SSL VPN Gateway’s private network IP address range or the client-assigned private IP address. The Firebox SSL VPN Gateway then transmits the packets to the network.

Note

Note: The Secure Access Client maintains two tunnels: an SSL tunnel over which data is sent to the Firebox SSL VPN Gateway and a tunnel between the client and local applications. The encrypted data that arrives over the SSL tunnel is then decrypted before being sent to the local application over the second tunnel.

If you run a packet sniffer such as Ethereal on the computer where the Secure Access Client is running, you will see unencrypted traffic that appears to be between the client and the Firebox SSL VPN Gate- way. That unencrypted traffic, however, is not over the tunnel between the client and the Firebox SSL VPN Gateway but rather the tunnel to the local applications.

When an application client connects to its application server, certain protocols may require that the application server in turn attempt to create a new connection with the client. In this case, the client

Administration Guide 121