Reverse Tunneling to Get Through TWT Blockage

Time Warner Telecom, our provider on Hawai`i, blocks inbound connections to our home/office border. I.e. one can not ssh or https to the OpenWRT router to configure/maintain it. For this they charge more than Comcast on Bainbridge Island, who also provides IPv6, and over twice what NTT/IIJ cost in Tokyo with IPv6 and 100/100mb.

So I bought a toy of the month, a Raspberry Pi, set it up per RaspberryPi, and with clue from sra, hacked an ssh reverse tunneling set-up as follows:

The ssh tunnel runs to a server on the public network, so one can connect to specially configured ports on that server and they will be reverse tunneled back to the Raspberry Pi inside the prison walls where they will be redirected appropriately. I will call this server Server.

On the public Server, I created an account, user tunnel, to contain the hack, and created an ecdsa ssh pair to be used.

su -l tunnel
ssh-keygen -t ecdsa -b 384

I moved the private key from ~tunnel/.ssh/id_ecdsa to the Raspberry Pi manually, deleting it on Server, and allowed the pi to ssh to Server with that private key by

cat .ssh/id_ecdsa.pub > .ssh/authorized_keys

On the Pi

mv id_ecdsa .ssh/tunnel_id_ecdsa
chmod 600 .ssh/tunnel_id_ecdsa

Now, I could ssh from Pi to Server as user pi and as user root. This was to test and to get Server's host key into both ~/.ssh/known_hosts.

One last hack is needed on the Server iff you want to access the tunneled ports through other than the loopback address. /etc/ssh/sshd_config takes the command

Match user tunnel
  GatewayPorts yes

You could use

Match user tunnel
  GatewayPorts clientspecified

if you intend to have the tunnels from the Pi use the four-field version of the -R option to specify the IP address on which the server should listen. Remember to restart the sshd service on Server.

Nothing more needed on Server. We now go over to the Pi.

I installed upstart, which gave dire warnings and seems to have some issues causing a few minute delay between boot and the system sshd coming up. I did not sort this out.

sudo apt-get install upstart

Hack /etc/network/interfaces to signal two events on up/down of the ethernet interface

auto eth0
  iface eth0 inet dhcp
  post-up  initctl emit --no-wait eth0-tunnel-hack-up   || true
  pre-down initctl emit --no-wait eth0-tunnel-hack-down || true

Create the upstart script to catch the ethernet events and start/stop the tunnel, /etc/init/tunnel-hack.conf

description "Wes George Memorial Tunnel"

author "randy@psg.com"

start on eth0-tunnel-hack-up
stop  on eth0-tunnel-hack-down

respawn

exec ssh -N -i /home/pi/.ssh/tunnel_id_ecdsa tunnel@Server \
  -R 40443:192.168.0.1:42443 \
  -R 40022:192.168.0.1:22 \
  -R 41022:localhost:22

After reboot, I could ssh to the Pi from the outside world using

ssh -p 41022 pi@Server

I could ssh to the OpenWRT

ssh -p 40022 root@Server

And access the OpenWRT's LuCI web interface in a browser with the url

https://Server:40443

I had stability problems, where the Pi ssh process was alive but there was nothing on the Server end. This was cured by adding

ServerAliveCountMax 5
ServerAliveInterval 60

to the Pi's /etc/ssh/ssh_config

3.3 KiB Raw Blame History

Reverse Tunneling to Get Through TWT Blockage

3.3 KiB

Raw Blame History