The Proxy can be used to "Forward" a request from a Client PC to a Server using the "Forwarding" features.
The diagram below shows this process, the client need to telnet to the Server on port 2000 but must go via the ProxySG. The ProxySG has a "TCP Tunnel" (in this example it is Explicit) service, it also has a "Forwarding Server".
As the traffic is NOT serviceable by the Proxy (e.g. HTTP, HTTPS...) the use of the Service type "TCP TUNNEL" is required. This allows the client to point to the ProxySG IP address on a specific port which the ProxySG will then, using policy, "Forward" this traffic onto the end server.
When creating this Service the "Detect Protocol" is NOT ticked as this can add up to "30 Secs" delay. The reason is that this feature is used to examine the incoming request and try to determine if the ProxySG can send it to one of the Engines (e.g. HTTP), So make sure this is not ticked.
If we look at the Forwarding Host, we can see the "type" is a server which allows us to tick the TCP: option and add the 2000 port.
This does not mean you have to use 2000 as this can be any port the Server is listening on.
If I now telnet to the ProxySG on port 2000 I am forwarded to the Server.
It has been noted that this initial connection can take up to a minute (or longer), where it should be instantaneous.
There are two factor to consider:
- we have already covered the "Protocol Detect" (above) - 30 Secs Delay
- RDNS (reverse domain name lookup), as the request is IP based and if you have any "content filter" or "access logging" that checks and records requests; this can be delayed if the DNS Server cannot find the lookup address.
Adding the following to the Local Policy File. (or in VPM) will stop the ProxySG from perform RDNS and reduce this delay.; stop the ProxySG from performing RDNS on the IP Address / Range