diff --git a/pages/ReverseTunnel.md b/pages/ReverseTunnel.md
new file mode 100644
index 0000000..03ff407
--- /dev/null
+++ b/pages/ReverseTunnel.md
@@ -0,0 +1,107 @@
+# 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](https://wiki.rg.net/wiki/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