Using a TCP Proxy to Forward Traffic to a SOCKS Next-hop Proxy

Last updated
Save as PDF

Web traffic coming in over the listener port of a TCP proxy on Web Gateway can be forwarded to a next-hop proxy that follows the SOCKS protocol.

The forwarding is then performed even for traffic that is not coming in under SOCKS. Handling web traffic in this way is sometimes referred to as SOCKSification.

To implement the forwarding, you need to create a suitable rule. A suitable rule set for this rule is the Next-Hop Proxy rule set, which you can import from the rule set library.

Next-hop proxy settings, which you can use for completing the next-hop proxy part of the configuration, are imported with the rule set.

Rule for forwarding traffic from a TCP proxy to a SOCKS next-hop proxy

The rule that forwards the traffic might look as the example shown here. It assumes that the listener port of the TCP proxy is 9102.

If traffic is coming in on this port, the rule event enables a next-hop proxy that runs under the SOCKS protocol. The event settings specify the details of this proxy.

Name
Forward traffic from a TCP proxy to a SOCKS next-hop proxy
Criteria                          Action     Event
Proxy.Port equals 9102         –> Continue — Enable Next-Hop Proxy<SOCKS Next-Hop>

Settings for a SOCKS next-hop proxy

The settings for the next-hop proxy that runs under SOCKS are configured as the settings of the event that enables this proxy. You can use the Next-Hop Proxy settings that are imported with the rule set as a starting point.

When creating the settings for the SOCKS next-hop proxy, you can keep the existing default list of next-hop proxies, but you need to add a proxy to this list.

The following values must be specified for this proxy:

Name
IP address and port
SOCKS protocol version

For the remaining next-hop proxy options, you can keep the default values.

Troubleshooting

When issues with proxies occur, connection traces or TCP dumps are helpful. TCP dumps can also be loaded into an analyzing tool, such as Wireshark, that "understands" SOCKS.

If an error occurs on the connection from the TCP proxy to the SOCKS next-hop proxy, for example, if the next-hop proxy can't be reached after performing the number of configured retries, the connection is closed.

The user who works with a client of Web Gateway might notice the closing. But because TCP and SOCKS don't support reasonable error reporting to the client, this is usually all that is noticed on the client.

If the next-hop proxy can detect an embedded protocol within SOCKS, for example, HTTP, a block page or a similar message might be sent to the client.