SSH Pivoting and Tunneling: Port Forwarding, SOCKS & sshuttle

You can SSH to a jump host. The jump can reach an internal web app you cannot hit from Kali directly. That reachability gap is what pivoting solves.

This lesson uses a small practice lab with addresses 10.10.10.x and 10.20.20.x. That is not the same flat 192.168.56.0/24 layout from pentest lab setup where Kali and Metasploitable share one host-only network. You still work on your existing Kali VM — the next section shows how to simulate the extra network on one machine.

In this lab you will:

• Build the two-segment topology on Kali with network namespaces
• Prove Kali cannot open the internal URL until a tunnel exists
• Reach one internal port with SSH local forwarding (-L)
• Expose a Kali listener back through the jump with remote forwarding (-R)
• Open a SOCKS path (-D), then wrap tools with ProxyChains
• Route a whole subnet with sshuttle, and note Metasploit route when the foothold is already a session

Pivoting vs port forwarding vs tunneling

People mix these three terms. Keep them separate and the rest of the page gets easier.

Port forwarding is a technique. Tunneling is the transport. Pivoting is the goal: work from your keyboard as if you sat on the far side of the jump.

Lab topology for network pivoting

Every command below assumes the three-role layout in the diagram. The IP plan is fixed on purpose so you can tell outer from internal at a glance.

Read the diagram left to right:

• Kali (10.10.10.1) talks to the jump over SSH on the outer segment
• Jump bridges outer (10.10.10.2) and internal (10.20.20.1)
• Internal HTTP (10.20.20.2:8080) sits on the internal segment only
• The dashed NO ROUTE line means a direct curl from Kali to 10.20.20.2 should fail until you open a tunnel

How this differs from the Group 1 pentest lab

If you built pentest lab setup, you already have Kali at 192.168.56.120 and Metasploitable at 192.168.56.127 on one host-only network. Both VMs can ping each other — there is no isolated internal segment and no jump host.

The 10.10.10.x range looks like the Proxmox GOAD lab subnet, but this lesson uses .1 / .2 and adds 10.20.20.0/24 so the two hops are obvious. You do not need GOAD or a second physical VM for this page — namespaces on Kali are enough.

Build the pivot practice lab on Kali

You need one Kali VM (pentest lab setup is fine). sudo builds two network namespaces — jump and internal — plus virtual Ethernet pairs so traffic flows the same way as the diagram.

Install the SSH server package if Kali does not already have it:

sudo apt update && sudo apt install -y openssh-server

Create a dedicated key pair for the lab jump login. A separate key keeps this practice lab off your personal SSH keys:

test -f ~/.ssh/pivot_lab || ssh-keygen -t ed25519 -f ~/.ssh/pivot_lab -N ""

Create the pivot account and install your lab public key before you bring up the namespaces:

sudo useradd -m -s /bin/bash pivot 2>/dev/null || true
sudo install -d -o pivot -g pivot -m 700 /home/pivot/.ssh
sudo install -o pivot -g pivot -m 600 ~/.ssh/pivot_lab.pub /home/pivot/.ssh/authorized_keys

Run the setup script below once. It creates namespaces, assigns the 10.10.10.x and 10.20.20.x addresses, starts a tiny HTTP server in internal, and runs sshd inside jump:

sudo bash -s <<'SETUP'
set -euo pipefail
cleanup() {
  pkill -f 'ip netns exec internal.*http.server' 2>/dev/null || true
  pkill -f 'sshd.*10.10.10.2' 2>/dev/null || true
  ip netns del jump 2>/dev/null || true
  ip netns del internal 2>/dev/null || true
  ip link del veth-outer 2>/dev/null || true
}
cleanup
ip netns add jump
ip netns add internal
ip link add veth-outer type veth peer name veth-jump-outer
ip link set veth-jump-outer netns jump
ip link add veth-jump-inner type veth peer name veth-internal
ip link set veth-jump-inner netns jump
ip link set veth-internal netns internal
ip addr add 10.10.10.1/24 dev veth-outer
ip link set veth-outer up
ip netns exec jump ip addr add 10.10.10.2/24 dev veth-jump-outer
ip netns exec jump ip link set veth-jump-outer up
ip netns exec jump ip link set lo up
ip netns exec jump ip addr add 10.20.20.1/24 dev veth-jump-inner
ip netns exec jump ip link set veth-jump-inner up
ip netns exec internal ip addr add 10.20.20.2/24 dev veth-internal
ip netns exec internal ip link set veth-internal up
ip netns exec internal ip link set lo up
ip netns exec internal bash -c 'mkdir -p /tmp/pivot-http && printf internal-service-ok > /tmp/pivot-http/index.html && exec python3 -m http.server 8080 --bind 10.20.20.2 --directory /tmp/pivot-http' &
ip netns exec jump /usr/sbin/sshd -D -p 22 -o ListenAddress=10.10.10.2 -o AllowTcpForwarding=yes -o GatewayPorts=no &
SETUP

The HTTP server and sshd run in the background inside their namespaces. Wait two or three seconds before you test SSH.

Confirm SSH to the jump works before you try forwarding:

ssh -o StrictHostKeyChecking=accept-new -i ~/.ssh/pivot_lab pivot@10.10.10.2 exit

A silent exit means authentication succeeded. If you see Connection refused, wait a few seconds and retry — sshd inside jump may still be starting.

Verify the reachability gap

Direct curl from Kali (your main shell) to the internal IP should fail. The curl command cheat sheet covers -m and -w if you want different status formats:

curl -s -m 2 -o /dev/null -w '%{http_code}\n' http://10.20.20.2:8080/

000

000 means curl never got an HTTP status. The internal address is not reachable from Kali without a pivot — that is expected.

From the jump namespace, the same URL should succeed. That proves the internal service is up and only the jump has a path to it:

sudo ip netns exec jump curl -s http://10.20.20.2:8080/

internal-service-ok

That contrast is the whole point of the article. The jump can already talk to the target. You need a tunnel so tools on Kali can borrow that path.

Add -i ~/.ssh/pivot_lab to every ssh command in the sections below unless you copied the key into your default agent.

Optional packet-path check while you test later techniques: on the jump, run sudo ip netns exec jump tcpdump -ni veth-jump-inner port 8080 and curl from Kali through a forward. You should see the jump talking to 10.20.20.2, not Kali speaking on that interface. Also watch for a misleading ip route get 10.20.20.2 on Kali that points at hypervisor NAT — that is broken lab isolation, not a pivot.

Decide which pivoting technique to use

Pick the smallest tool that matches the job, then jump to that section:

Ligolo-ng, Chisel, multi-hop chains, and Windows-native forwarding belong in dedicated pages. This article stays on SSH-first fundamentals that every PenTest+ lab still needs.

A single -L forward is easier to explain in a report than a standing SOCKS proxy with half your desktop pointed at it.

Local port forwarding with SSH -L

Use local forwarding when you know one destination port and you want a listener on Kali. Think of it as: “make 127.0.0.1:18080 on my machine secretly mean 10.20.20.2:8080 via the jump.”

Traffic flow:

1. Your client connects to 127.0.0.1:18080 on Kali.
2. SSH carries the bytes to the jump.
3. The jump opens 10.20.20.2:8080 and relays the reply.

Flag meanings in the command below:

• -f — background the SSH client after auth
• -N — do not open a remote shell; only forward ports
• -o ExitOnForwardFailure=yes — exit if the requested forward cannot bind (default OpenSSH leaves the session up even when a forward fails)
• -L 127.0.0.1:18080:10.20.20.2:8080 — listen on Kali loopback 18080, send that traffic to 10.20.20.2:8080 from the jump

The SSH command cheat sheet covers other client flags if you need a refresher beyond forwarding:

ssh -f -N -o ExitOnForwardFailure=yes -i ~/.ssh/pivot_lab -L 127.0.0.1:18080:10.20.20.2:8080 pivot@10.10.10.2

If SSH returns successfully, the requested listener was established. Verify it with ss or the application test below. Hit the local port, not the internal IP:

curl -s http://127.0.0.1:18080/

internal-service-ok

Success looks like the same body the jump saw earlier. Kali still has no route to 10.20.20.2; curl only talked to 127.0.0.1, and SSH did the rest. Stop this forward with kill on the SSH PID before you pile on another technique, or use a fresh terminal after cleanup.

Remote port forwarding with SSH -R

Remote forwarding reverses the direction. Instead of “bring the internal port to Kali,” you “publish something on Kali so the jump can fetch it.”

Typical lab use:

• A callback or local tool that must listen on Kali
• A host deeper in the lab that can only talk to the jump, not to Kali directly

Start a tiny HTTP directory listing on Kali loopback so there is something to fetch:

python3 -m http.server 9191 --bind 127.0.0.1

Leave that running in one terminal. In another, create a remote forward so the jump’s 127.0.0.1:9191 points at Kali’s 127.0.0.1:9191:

ssh -f -N -o ExitOnForwardFailure=yes -i ~/.ssh/pivot_lab -R 127.0.0.1:9191:127.0.0.1:9191 pivot@10.10.10.2

In this -R command, the first 127.0.0.1:9191 belongs to the jump host. The destination 127.0.0.1:9191 is resolved from Kali, where the Python server is listening. Those are two different loopbacks.

If SSH returns successfully, the remote listener was set up. From the jump, curl it:

sudo ip netns exec jump curl -s -m 3 http://127.0.0.1:9191/ | head -n 5

<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Directory listing for /

Seeing the Python directory HTML means the jump reached Kali’s loopback through the SSH session. That is the opposite direction of -L.

Direction checklist:

• -L = listener on your side; destination is beyond the jump
• -R = listener on the jump; destination is on your side

If GatewayPorts is off (the default on many hosts), remote binds stay on the jump’s loopback only. That is what you usually want in a lab.

Dynamic SOCKS forwarding with SSH -D

Dynamic forwarding turns the jump into a SOCKS proxy. SOCKS is a simple rule: your client asks the proxy to open a TCP connection for it. The proxy (here, the SSH jump) opens that connection from its own network view.

Compared with -L:

• -L = one fixed destination you chose when you started SSH
• -D = many destinations, chosen later by each SOCKS-aware client

Start a SOCKS5 listener on Kali loopback:

ssh -f -N -o ExitOnForwardFailure=yes -i ~/.ssh/pivot_lab -D 127.0.0.1:1080 pivot@10.10.10.2

If SSH returns successfully, the SOCKS listener is up. Ask curl to connect through that proxy. Prefer --socks5-hostname so the name or IP is sent to the proxy (important later for DNS):

curl -s --socks5-hostname 127.0.0.1:1080 http://10.20.20.2:8080/

internal-service-ok

Getting the service body without a local -L port means SOCKS is working. You now have a general-purpose TCP path. The next section wraps everyday tools that do not speak SOCKS themselves into that same listener.

ProxyChains over a SOCKS proxy

ProxyChains (proxychains4 on Kali) forces many TCP clients through a SOCKS or HTTP proxy. It is the bridge when the tool does not have a built-in SOCKS option.

What it can and cannot do:

• Works for many TCP CLI tools when you prefix them with proxychains4
• Does not proxy UDP, ICMP, or raw SYN scans
• Works by hooking socket-related calls in dynamically linked programs; static binaries and some programs that bypass or complicate those libc hooks may not proxy correctly

Create a small config that points at the SOCKS listener from the previous section:

cat > /tmp/proxychains-pivot.conf <<'EOF'
strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
socks5 127.0.0.1 1080
EOF

Config lines that matter here:

• strict_chain — fail if the proxy is down (safer than silently going direct)
• proxy_dns — resolve names through the proxy instead of leaking DNS on Kali
• socks5 127.0.0.1 1080 — your ssh -D listener

Wrap curl with that file:

proxychains4 -f /tmp/proxychains-pivot.conf -q curl -s http://10.20.20.2:8080/

internal-service-ok

Same body as before means the wrapper reached the internal host through SOCKS. The same path works for TCP connect scans. Use -sT so Nmap opens real TCP sockets ProxyChains can intercept:

proxychains4 -f /tmp/proxychains-pivot.conf nmap -sT -Pn -n -p 8080 10.20.20.2

[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-05 10:13 -0400
[proxychains] Strict chain  ...  127.0.0.1:1080  ...  10.20.20.2:8080  ...  OK
Nmap scan report for 10.20.20.2
Host is up (0.00s latency).

PORT     STATE SERVICE
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds

Read the outcome like this:

• Strict chain ... OK — the probe went through SOCKS, not Kali’s direct interface
• 8080/tcp open — the internal service accepted the connect through the jump

For broader Nmap recon habits, remember ProxyChains only helps connect-oriented paths. Raw SYN scans bypass the preload.

sshuttle for subnet-style routing over SSH

sshuttle feels closer to a VPN than to a single port forward. You give it a CIDR; it installs local firewall rules and forwards matching TCP through SSH.

What you get:

• Transparent TCP to the listed subnet (no proxychains4 prefix on every command)
• Still needs a working SSH login to the jump
• Needs sudo (or root) on Kali for the firewall helper
• Still TCP-focused; prove IPs first, then optional --dns (see below and the DNS section)

With the internal HTTP service still up, tunnel the whole 10.20.20.0/24 range through the jump. Set PIVOT_KEY so sudo can pass the correct path to ssh. Verbose mode prints the method and the connect line; leave the process running after it connects:

PIVOT_KEY="$HOME/.ssh/pivot_lab"
sudo sshuttle -r pivot@10.10.10.2 --ssh-cmd "ssh -i $PIVOT_KEY" 10.20.20.0/24 -v

c : Starting firewall manager with command: ['/usr/bin/sshuttle', '-v', '--method', 'auto', '--firewall']
c : Method: nat
c : Connected to server.

What those lines mean:

• Method: nat — sshuttle chose NAT firewall rules on this host
• Connected to server. — the SSH side of the tunnel is up; keep this process running

In another terminal, curl the internal IP without SOCKS or ProxyChains:

curl -s -m 5 http://10.20.20.2:8080/

internal-service-ok

Success here is the important contrast with ProxyChains: a normal curl to the real internal IP works because the host firewall sent that TCP into sshuttle.

When you intentionally want matching DNS requests resolved on the remote side, add --dns. Prove IP connectivity first, then enable DNS:

PIVOT_KEY="$HOME/.ssh/pivot_lab"
sudo sshuttle --dns -r pivot@10.10.10.2 --ssh-cmd "ssh -i $PIVOT_KEY" 10.20.20.0/24

Use --dns only after the plain CIDR tunnel already returns internal-service-ok. Stopping the earlier sshuttle process first avoids overlapping firewall rules.

Compared with ProxyChains:

If auto fails on a host with a busy nftables stack, try --method nft or --method tproxy and retest with a short curl. Stop sshuttle with Ctrl+C in its terminal (or kill the daemon PID if you used --daemon).

Metasploit routing through a session

Use this path when your foothold is already a Meterpreter (or compatible) session, not an SSH login. Metasploit can send module traffic through that session the way SSH sent traffic through the jump. Full session work lives in the Metasploit tutorial.

From msfconsole, route documents the idea: add a subnet that should exit via a session ID:

msfconsole -q -x 'help route; exit'

Route traffic destined to a given subnet through a supplied session.

Usage:
  route [add/remove] subnet netmask [comm/sid]
  route [add/remove] cidr [comm/sid]
  route [get] <host or network>
  route [flush]
  route [print]

Examples:
  Add a route for all hosts from 192.168.0.0 to 192.168.0.255 through session 1
    route add 192.168.0.0 255.255.255.0 1
    route add 192.168.0.0/24 1

After you have a live session that can reach the internal net, the practical steps look like this:

• route add 10.20.20.0/24 1 — send that CIDR through session 1
• route print — confirm which CIDRs actually go through the session
• use auxiliary/server/socks_proxy — open a SOCKS listener inside Metasploit, then point ProxyChains at it the same way you did for ssh -D

The current post/multi/manage/autoroute module can discover and add routes from a session. Always verify the result with route print.

DNS through tunnels and common leaks

TCP to an IP can work while name-based tools still fail. DNS often leaves the tunnel.

Practical habit for labs:

• Prove the pivot with IP literals first
• Add internal hostnames only after SOCKS DNS or sshuttle DNS is confirmed
• If a browser works for an IP bookmark but fails for a hostname, suspect DNS leak before you rebuild the tunnel

Troubleshooting pivoting and tunnels

Cleanup forwards, routes, and listeners

Leave the lab quieter than you found it. Tear down in this order:

1. Stop application listeners you started (python3 -m http.server on Kali loopback, not the namespace HTTP server yet).
2. Kill SSH forwards (-L, -R, -D). Each is its own ssh process.
3. Stop sshuttle (Ctrl+C or daemon PID) so firewall rules disappear.
4. In Metasploit, route flush and stop socks_proxy if you used them.
5. Remove temporary ProxyChains config files you created under /tmp.
6. Tear down the namespace practice lab when you are finished with the whole lesson:

sudo pkill -f 'ip netns exec internal.*http.server' 2>/dev/null || true
sudo pkill -f 'sshd.*10.10.10.2' 2>/dev/null || true
sudo ip netns del jump 2>/dev/null || true
sudo ip netns del internal 2>/dev/null || true
sudo ip link del veth-outer 2>/dev/null || true

Confirm nothing is still listening on the lab ports:

ss -ltnp | grep -E '1080|18080|9191' || true

No matching lines means the common lab listeners are gone. Re-check direct curl to 10.20.20.2 still returns 000 from your main Kali shell if you left the namespace lab up — that confirms isolation is still correct.

Summary

SSH pivoting means borrowing a dual-homed host’s reachability through an encrypted session. On this practice lab, Kali at 10.10.10.1 could not open 10.20.20.2:8080 until a forward or tunnel carried the traffic — even though both addresses live on the same physical Kali VM.

Match the tool to the job: -L for one local listener, -R when the jump needs a path back to Kali (including reverse-shell callbacks), -D plus ProxyChains for many TCP clients, and sshuttle when you want transparent TCP to a whole CIDR. Metasploit route and socks_proxy cover the case where the foothold is already a framework session instead of an SSH login. Ligolo-ng and Chisel stay out of this fundamentals page on purpose.

The usual failure is not the syntax. It is skipping the namespace lab build, verifying the wrong address, leaking DNS off-tunnel, or leaving an old forward bound. Use ExitOnForwardFailure=yes, prove before/after reachability, prefer the smallest technique that matches the task, and clean up listeners and namespaces before you write the finding.

References

• OpenSSH SSH client manual (ssh) — -L, -R, -D forwarding
• sshuttle project documentation — transparent TCP over SSH
• proxychains-ng — TCP proxy wrapper
• Metasploit Framework documentation — sessions, routing, and modules