Original Destinations in Transparent TCP-to-SOCKS Forwarding
Explain why transparent TCP-to-SOCKS forwarding needs a translator that recovers the original destination before negotiating with the proxy.
A firewall can change where a TCP connection lands. It cannot, by that change alone, teach the originating application to speak SOCKS.
An ordinary SOCKS server expects a negotiation describing the requested destination. An application unaware of the proxy instead sends its own protocol bytes immediately. Redirect those bytes straight to a SOCKS listener and the two sides disagree about the first message.
The missing component is a translator
A transparent TCP-to-proxy component sits between those interfaces. It discovers the destination the application originally requested, establishes the appropriate SOCKS or HTTP CONNECT session, and then relays application data over the resulting stream.
On its Linux iptables path, the redsocks source retrieves the preserved destination using SO_ORIGINAL_DST. Other operating systems and redirection methods use different mechanisms. This is a property of the redirector and network setup, not an ordinary SOCKS client feature.
Original-destination information also explains why moving a redirection rule from the proxy host to an unrelated gateway is not always equivalent. The receiving process needs the metadata required by its interception mode. An address rewritten elsewhere may no longer provide that information in the expected form.
Keep the scope of the translator explicit. A working redirected TCP connection does not establish support for arbitrary UDP, ICMP, or every resolver path. The upstream proxy protocol and the translator's implementation still define the supported operations.
When a setup fails immediately after connection, check the protocol boundary before broadening access rules. A perfectly reachable SOCKS listener can reject bytes that were never a SOCKS request.