Dynamic Port Forwarding with SOCKS

Dynamic forwarding turns SshTunnel into a local SOCKS4 or SOCKS5 server. Unlike static forwarding, the destination is supplied by each SOCKS client request rather than by DestHostname and DestPort.

Dynamic SOCKS port forwarding architecture A SOCKS-aware client process connects to a local SOCKS5 listener on port 1080. Chilkat background threads in the application process read the destination from each SOCKS request and carry the traffic through SSH. The remote SSH server opens a different destination connection for each request. LOCAL COMPUTER SOCKS-Aware Client ProcessBrowser or another applicationSOCKS5 = 127.0.0.1:1080Each request supplies its owndestination hostname and port. Your Application Process Application threadDynamicPortForwarding = trueInboundSocksVersion = 5BeginAccepting(1080)DestHostname / DestPort are unused Chilkat background threadsAct as the local SOCKS serverParse each SOCKS destinationOpen an SSH channel per requestRelay bytes in both directionsNo separate SOCKS daemon controls SOCKS protocol REMOTE NETWORK SSH Server ProcessOpens each destination selectedby the inbound SOCKS client.Destinations are reached here. Web APIapi:443request A Databasedb:5432request B Other TCPrequest C Encrypted SSH

The local client must understand SOCKS. Chilkat parses the SOCKS request inside the application process and opens the requested destination through the SSH server.

Chilkat object or managed thread Separate process or application code SSH server or remote network component Destination service Local-computer boundary

Where each part runs

PartLocationExecution form
SOCKS-aware clientUsually the local computerSeparate browser, tool, or application process configured to use a SOCKS proxy
SOCKS listenerLocal computer, inside your application processChilkat listener background thread
SOCKS parsing and SSH relaySame application processChilkat tunnel-pool and client background threads
SSH serverRemote computerSeparate SSH server process that opens each requested destination
Destination servicesRemote or internal networkPotentially many separate service processes

Required settings

tunnel.DynamicPortForwarding = true
tunnel.InboundSocksVersion = 5
tunnel.ListenBindIpAddress = "127.0.0.1"

success = tunnel.Connect("ssh.example.com", 22)
// Verify HostKeyFingerprint, then authenticate.
success = tunnel.AuthenticatePk("ssh-user", privateKey)
success = tunnel.BeginAccepting(1080)

When DynamicPortForwarding is true, DestHostname and DestPort are unused. Set InboundSocksVersion to 4 or 5.

Optional inbound SOCKS5 authentication

Set InboundSocksUsername and InboundSocksPassword when clients must authenticate before using the local SOCKS5 listener. When no inbound username is configured, the listener does not require SOCKS authentication. SOCKS4 does not provide password authentication.

Do not expose an open proxy: A dynamic listener bound to a non-loopback interface can become a network-accessible SOCKS proxy. Bind to 127.0.0.1 unless remote clients are intentionally allowed, and require authentication when exposure beyond the local computer is necessary.

Inbound SOCKS versus outbound SOCKS

PurposePropertiesDirection
Dynamic forwarding listenerDynamicPortForwarding, InboundSocksVersion, InboundSocksUsername, InboundSocksPasswordA client connects into SshTunnel.
Reach the SSH server through an existing SOCKS proxySocksVersion, SocksHostname, SocksPort, SocksUsername, SocksPasswordSshTunnel connects outward through a proxy.

When dynamic forwarding is appropriate

  • One browser or tool must reach several remote hosts through the SSH server.
  • The destination changes per connection.
  • The client software already supports SOCKS4 or SOCKS5 configuration.

Use static forwarding instead when the client does not support SOCKS or when a stable local-port-to-destination mapping is simpler.