Operation Through Firewalls And Proxies; Terminating The Secure Tunnel And Returning Packets To The Client - Watchguard SSL 1000 User Manual

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: 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
Connecting from a Private Computer
Note
121