Route a selected subnet through sshuttle

Needs: Working SSH/Python environment, local routing/firewall privileges and explicitly selected supported traffic/subnets

Shell commands

# Baseline
sudo sshuttle --dns \
  -r SSH_USER@PIVOT:SSH_PORT \
  INTERNAL_SUBNET ANOTHER_SUBNET

# Through a previously established local forward to the SSH pivot
sudo sshuttle --dns \
  -r SSH_USER@127.0.0.1:LOCAL_SSH_PORT \
  INTERNAL_SUBNET

sshuttle is useful when many TCP clients need transparent access. It requires privileges and firewall/redirection support on the client; the remote side needs a compatible Python execution path. It is not a general layer-2 VPN and does not make arbitrary raw-packet or UDP behavior equivalent to direct routing. Record the selected subnets so existing VPN routes are not accidentally captured.

Verify → Verify the actual application path and ensure only assigned subnets are selected.

If it fails → Missing local privilege, remote runtime or unsupported traffic can break this option. Use fixed forwards/SOCKS or a compatible routed tunnel. More detail ↓

If → then

An IP connection works while hostname/Kerberos access fails → Preserve DNS, Kerberos names and time across a pivot
Needs: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time
A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization
Needs: Real source-to-service route, correct identity context and protocol-specific execution/logon rights
Several internal TCP services need access through one SSH server → Provide SOCKS access through SSH dynamic forwarding
Needs: SSH forwarding allowed and clients that support SOCKS or compatible interception; DNS behavior must be chosen explicitly

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Route a selected subnet through sshuttle

USE WHEN: Multiple internal TCP destinations need transparent application access over SSH
STARTING ACCESS: A pivot identity/process or reachable SSH service and a drawn source-to-destination path
RESULT: A verified transparent route for the chosen supported traffic

Recognize the clue

Identify several internal TCP destinations, existing SSH access and whether the local/remote privilege/runtime requirements can be met.

ssh -v USER@PIVOT
python3 --version
ip route

SYNTHETIC EXAMPLE OUTPUT

SSH path: accepted
Local routing/firewall context: inspect
Remote Python support: inspect in SSH context

Means: An SSH carrier and compatible endpoints make a transparent selected-subnet route a candidate; local Python output alone does not prove the remote runtime.

Confirm: Verify local route/firewall permissions, remote runtime, supported transport/mode and explicitly selected subnet/DNS behavior.

After validation: The selected application traffic works through the compatible mode: choose sshuttle.
Ruled out in this context: Required local permission or remote support is unavailable: reject this route implementation.
Still inconclusive: TCP success does not establish unsupported UDP/raw behavior; test the actual requirement.

Troubleshooting: Missing local privilege, remote runtime or unsupported traffic can break this option. Use fixed forwards/SOCKS or a compatible routed tunnel.

Additional prerequisite checks

ssh -v USER@PIVOT
python3 --version

Through a previously established local forward to the SSH pivot:

sshuttle is useful when many TCP clients need transparent access. It requires privileges and firewall/redirection support on the client; the remote side needs a compatible Python execution path. It is not a general layer-2 VPN and does not make arbitrary raw-packet or UDP behavior equivalent to direct routing. Record the selected subnets so existing VPN routes are not accidentally captured.

Why it works

sshuttle redirects selected application traffic rather than providing an unrestricted raw-packet VPN. DNS handling and supported transports depend on its selected mode/platform.

Worked example · hypothetical

Observation: repeated proxy configuration is hindering several TCP clients. Test: route the selected subnet with the documented sshuttle settings and confirm a service. Illustrative output: a direct-style TCP application reaches the destination. Interpretation: validate DNS and unsupported transports separately.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗