Watchguard Firebox SSL Series, User Manual

Page: 37 / 198

Administration Guide 27
Using the Firebox SSL VPN Gateway
NAT firewalls maintain a table that allows them to route secure packets from the Firebox SSL VPN Gate-
way back to the client computer. For circuit-oriented connections, the Firebox SSL VPN Gateway main-
tains 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 friendly and allows remote computers to access private networks from behind other organiza-
tions’ 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
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
Gateway. 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.
The Secure Access Client maintains two tunnels: an SSL tunnel over which data is sent to the Firebox SSL
VPN Gateway (the sniffer also detects this tunnel) 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. The packet sniffer sees the second tunnel’s traffic, which
appears to be from the Firebox SSL VPN Gateway, after the traffic is already decrypted.
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
sends its known local IP address to the server by means of a custom client-server protocol. For these
applications, the Secure Access Client provides the local client application a private IP address represen-
tation, which the Firebox SSL VPN Gateway uses on the internal network. Many real-time voice applica-
tions and FTP use this feature.
Performance and Real-Time Traffic
Real-time applications, such as voice and video, are implemented over UDP, because TCP is not appro-
priate for real-time traffic due to the delay introduced by acknowledgements and retransmission of lost
packets. It is more important to deliver packets in real time than to ensure that all packets are delivered.
However, with any tunneling technology over TCP, such real-time performances cannot be met.
The Firebox SSL VPN Gateway overcomes this issue by routing UDP packets over the secure tunnel as
special IP packets that do not require TCP acknowledgements. Even if the packets get lost in the net-