Table of Contents

• Introduction
• Socket Hooking Approaches
• Firewall-Based Redirection
• TUN Device-Based Approaches
• SSH Port Forwarding
• Tor-Specific Solutions
• Comparison Table
• Recommendations
• Conclusion

Repository: rofl0r/proxychains-ng

ProxyChains-NG is a preloader that uses LD_PRELOAD to hook socket-related libc functions, including connect(), and redirect them through SOCKS proxies. It's the most mature and widely-used tool in this category.

How It Works

The tool injects itself into dynamically linked programs before they execute, replacing socket functions with versions that route traffic through configured proxies. It supports multiple proxy types (SOCKS4, SOCKS5, HTTP) and can chain them together.

Usage Example

$ proxychains telnet target.example.com
$ proxyhains -f /etc/proxychains-other.conf ssh user@example.com

Repository: Dante SOCKS Server

Dante, a commercial SOCKS server implementation, also provides socksify--a simple LD_PRELOAD wrapper script for redirecting applications through a SOCKS proxy.

Usage Example

$ socksify telnet target.example.com
$ socksify ssh user@example.com

Repository: tsocks on SourceForge

tsocks is an older LD_PRELOAD-based solution that provides transparent SOCKS4 and SOCKS5 proxy access. While mature, it's less actively maintained than ProxyChains-NG.

Repository: darkk/redsocks

redsocks is a transparent TCP-to-proxy redirector that uses Linux iptables (or BSD ipfw/pf with limitations) to intercept TCP traffic and forward it through a SOCKS or HTTP proxy. It's designed to work seamlessly with OpenSSH's dynamic forwarding feature.

How It Works

redsocks intercepts connections redirected by iptables, establishes them through the configured SOCKS proxy, and acts as a transparent intermediary. The flow is: application → kernel redirect → redsocks → SOCKS proxy → destination.

iptables Configuration Example

# Create redsocks chain
$ iptables -t nat -N REDSOCKS

# Ignore private networks
$ iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
$ iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
$ iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN

# Redirect remaining traffic to redsocks
$ iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345

# Apply to specific user traffic
$ iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner username -j REDSOCKS

Repository: mezantrop/ts-warp

ts-warp is a modern, cross-platform proxy client and server supporting SOCKS4/5, HTTP CONNECT, and SSH protocols. Unlike redsocks (which only works with SOCKS proxies), ts-warp can act as either a client or server, offering greater flexibility.

Key Features

• Transparent proxy on Linux (iptables/nftables) and BSD (pf) and macOS (pf)
• Policy-based routing with multi-proxy rules
• Supports both IPv4 and IPv6
• Internal SOCKS5 and HTTP proxy servers
• Proxy workload balancing
• Deep Packet Inspection (DPI) evasion support

Repository: xjasonlyu/tun2socks

tun2socks creates a TUN (network tunnel) device that intercepts TCP and UDP traffic at the network layer. It uses the gVisor TCP/IP stack to process traffic and forward it through a SOCKS proxy. This approach works with any application and any type of binary.

How It Works

Usage Example

$ tun2socks --device tun0 --proxy socks5://localhost:1080

Repository: sensepost/wiresocks

WireSocks combines WireGuard VPN with tun2socks to transparently proxy application traffic through SOCKS. It's particularly useful when other proxy methods fail, as it operates at the VPN level.

Architecture

The solution works by running a WireGuard server (inside Docker) on a jump box, with the WireGuard client on the host machine connecting to it. Traffic from the client is captured by tun2socks (inside another Docker container) and forwarded through a SOCKS proxy connected to the target network or Internet.

Setup Overview

Host Machine                   Docker Containers (Server)
┌──────────────────┐            ┌─────────────────────┐
│ WireGuard Client │◄──────────►│ WireGuard Server    │
│  Tools           │            │ + tun2socks         │
└──────────────────┘            └─────────────────────┘
                                        ↓
                                   SOCKS Server
                                        ↓
	  		      Target network/Internet

Use Case

WireSocks is particularly valuable for Windows users running offensive security tooling or network tools in general that don't respect traditional proxy settings. It's also useful on macOS for applications that can't be easily proxified through other means.

SSH's local port forwarding (-L) creates a local listening socket that forwards connections to a remote server, useful for accessing services on a remote network.

Usage Example

$ ssh -L 127.0.0.1:8080:internal-service.example.com:80 gateway.example.com
# Now access http://127.0.0.1:8080 to reach the remote service

Remote port forwarding (-R) does the opposite: it creates a listening socket on a remote host that forwards connections from a local service, making a local service accessible on the remote host.

As covered in our containerized SOCKS proxy post, SSH's -D option creates a SOCKS proxy directly:

$ ssh -D 1080 gateway.example.com

OpenSSH supports creating ad-hoc VPNs by tunneling TUN devices over SSH, as documented in the OpenSSH Cookbook.

How It Works

This approach creates a TUN interface on both the local and remote machine, connects them through SSH, and configures routing to send traffic through the tunnel. This effectively creates a VPN without additional software.

Setup Example

# On client machine:
$ ssh -f -w 0:1 192.0.2.15 true
# -f to send to background
# -w 0:1 because we have tun0 and tun1 on the local and remote side, respectively
# true is the command executed on the remote server; can use other commands
$ ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# 10.1.1.1 is the client's tun0 device
# 10.1.1.2 is the server's tun1 device
$ route add 172.16.99.0/24 10.1.1.2
# 172.16.99.0/24 is the VPN on the server side

# On server machine:
$ ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# 10.1.1.2 is the server's tun1 device
# 10.1.1.1 is the client's tun0 device
$ route add 10.0.50.0/24 10.1.1.1
# 10.0.50.0/24 is the VPN on the client side

Repository: sshuttle/sshuttle

sshuttle automates the process of creating a VPN tunnel over SSH using iptables (Linux) or pf (BSD) to handle packet routing. It's simpler than manual TUN configuration and more intuitive for end users, while potentially performing better.

Usage Example

$ sshuttle -r user@gateway.example.com 172.16.99.0/24 10.0.50.0/24
# Now all traffic to those subnets routes through SSH

Repository: Tor Project: torsocks

torsocks is the Tor project's LD_PRELOAD solution for routing individual applications through Tor. It's similar to ProxyChains-NG but optimized for Tor's SOCKS interface.

Usage Example

$ torsocks ssh user@example.com
torsocks curl https://ifconfig.me

Website: Whonix Project

Whonix is a Linux distribution designed from the ground up to route all traffic through Tor. It uses a two-virtual-machine architecture: a workstation for user applications and a gateway for Tor and routing.

Architecture

• Whonix-Gateway: Runs Tor, firewall rules, and SOCKS proxy. Only connects to Tor.
• Whonix-Workstation: User applications run here. All traffic forced through gateway.

Website: Tails Live Operating System

Tails is a complete Tor-focused Linux distribution that runs live from USB or DVD. Unlike Whonix's permanent approach, Tails leaves no traces on the system and automatically routes all traffic through Tor.

Documentation: Tor TransparentProxy, IsolatingProxy

These are architectural patterns for routing traffic through Tor using iptables (Linux) or pf (BSD). TransparentProxy routes all traffic directly to Tor, while IsolatingProxy uses a dedicated gateway machine to avoid information leakage.

TransparentProxy Pattern

Uses Linux iptables or BSD pf to redirect TCP and UDP traffic to Tor's SOCKSPort and DNSPort. Simple but may have information leakage issues.

IsolatingProxy Pattern

Uses a separate gateway machine running SOCKS proxy for Tor, with workstations connecting only through the gateway. Prevents accidental clearnet leaks.

Repository: Whonix/uwt

uwt is a simple wrapper that forces applications to use torsocks and provides fake system time to prevent time-based de-anonymization. Whonix pre-configures common CLI tools with uwt.

Usage Example

$ uwt ssh user@example.com
$ uwt dig example.com

Single Application, No Root Access

Recommended: ProxyChains-NG or torsocks (for Tor)

These LD_PRELOAD approaches work with most dynamically linked applications and require no elevated privileges. They're ideal for quick setup without system-wide changes.

All Applications, Need Root Access, Linux Only

Recommended: redsocks (for SOCKS) or sshuttle (for SSH)

Firewall-based redirection provides system-wide coverage without per-application configuration. redsocks is minimal and efficient; sshuttle adds convenience for SSH tunneling.

All Applications, Cross-Platform Support

Recommended: tun2socks or ts-warp

TUN-based approaches work on all major platforms and support all binary types. tun2socks is lighter; ts-warp offers more features and policy routing.

Windows/macOS Offensive Security Tooling

Recommended: WireSocks

Offensive security tools often ignore system proxy settings. WireSocks' WireGuard-based approach reliably captures all traffic without relying on system proxy mechanisms.

Complete Tor Anonymity

Recommended: Whonix (for security-conscious users) or Tails (for convenience)

These distributions provide comprehensive Tor integration with built-in leak prevention. Whonix is better for persistent use; Tails is better for ad-hoc anonymity.

SSH Tunneling to Remote Networks

Recommended: sshuttle or manual SSH TUN setup

sshuttle automates the complexity of TUN configuration. Manual setup offers more control if you need non-standard routing.