How to circumvent Firewall blocks

How to circumvent Firewall blocks

This a quick guide on how to use ssh tunneling


Local Tunneling

In the below example, we can assume that you are allowed to ssh to 192.168.0.135 BUT you are not allowed to RDP to that machine.

ssh -L 8181:192.168.0.135:3389  [email protected]

Traffic sent to localhost:8181 on your machine is forwarded to 192.158.0.135, port 3389 via 192.168.0.135, bypassing the firewall blocking.


Forward Tunneling

In the below example, we can assume the following

  • You are allowed to ssh to 192.168.0.2 (next hop)
  • You are NOT allowed to ssh to 192.168.0.3 (end host)
  • 192.168.0.2 IS allowed to ssh to 192.168.0.3

Stage It

ssh [email protected] -fNL 8081:192.168.0.3:22

Explaining the flags

  • -f: This option tells SSH to run in the background after asking for the password (useful for persistent tunnels).
  • -N: Instructs SSH not to execute a remote command. It's used for forwarding ports only.
  • -L : Sets up local port forwarding, (to 192.168.0.3) on the intermediary PC. (from 192.168.0.2)

SSH to localhost

ssh end-host-username@localhost -p 8081

You can also now copy files etc

scp -r -P 8081 end-host-username@localhost:/path/to/files .

Dynamic port forwarding

The below example assume

  • You are allowed to SSH to 192.168.0.135
  • You are NOT allowed to do anything else (ie browse web etc)

ssh -D 8181 [email protected] 

This creates a dynamic "Socks proxy"

Essentially all connections to localhost 8081 will be forwarded through the tunnel, to 192.168.0.135.
You can then enable "Socks" proxy on any browser, and once this is set up, all web requests will be forwarded to 192.168.0.135.
Dont forget to kill the process after you are done, with sudo ps -aux | grep 8081 and then kill pid


Reverse tunneling

Example: Remoting into work computer from home, or setting up a backdoor on a victim

on work computer/victim

ssh -R 8181:localhost:3389 [email protected] 

on the other PC (when you get home)

open up RDP and connect to port localhost:8181
If this fails, then check /etc/ssh/sshd_config for the following:

GatewayPorts yes
AllowTcpForwading yes

The Elephant in the room

When using SSH tunneling, you're essentially encapsulating one TCP connection inside another, which can lead to inefficiencies and issues:

  • Interference between congestion control mechanisms
  • Increased latency and jitter
  • Head-of-line blocking
  • Inefficient use of bandwidth
  • Buffer bloat

This is where sshshuttle comes in.
In summary:

sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It’s just data-over-TCP, which is safe.

sudo sshuttle -r user@server 0/0

This will tunnel everything 0.0.0.0/0to a remote host