Recently I have been thinking about a project we did a year back, where we customized NGrok code to create a tunneling solution that will connect an AWS based browser to a client’s on premise web-server for a functional testing product (Microfocus SRF). I always thought that Protocol tunneling is an exciting concept, a cleaver way of creeping under the radar getting away with sending requests in the opposite direction, drilling holes through smothering protection and setting up impossible connections.

I thought of creating something similar that will help defend home automation setups, and meld together work & home environments without using port mapping, setting up VPNs, or heavily affecting network performance. Teleporter is what I came up with, written from the ground up over muxado, and it is easy as pie to setup.

Usage

So before explaining any further, here is how to use it:

For a demo on your local machine:

Download the latest build of Teleporter Use “run.bat” in any of the examples to run several nodes on localhost Configure your browser to use the socks5 proxy now running on localhost:10101 to see it in action.

To set up a real network:

Spin up some free tier cloud machine (GCP will give you $300 for a year, with no obligations, just by feeding in credit card info, AWS free tier machines are also an option) Place a node on that machine & open the relay port to the public Deploy teleport nodes on your favorite machines & configure (see below) to construct your own custom slice of internet!

The Configuration file structure:

The config is designed to be mostly self-explanatory, it holds all the information for creating listeners, establishing connections and restricting network access. The default rule is to deny access, currently requests will be routed to the first node that allows the requested address.

The Teleport configuration file is split into 3 sections:

Servers : create listeners of 2 different types: socks5 proxy & relay

: create listeners of 2 different types: socks5 proxy & relay Tethers : define connections to relay ports on other nodes

: define connections to relay ports on other nodes netConf: includes the node’s ID and mapping rules that allow access to resources reachable from this node, this part of the configuration is sent out to other nodes when connecting to them, this enables smart routing. the mapping rules are executed sequentially, they state which node will be chosen next for the route, choosing “local” means the request has reched it’s destination and should run on the current machine.

{

"servers": [

{

"port": 10101,

"type": "socks5",

"acceptLocalOnly": true,

"useAuthentication": true,

"authClients": {

"socks5User": "<SECRET STRING>"

}

}

],

"tethers": [

{

"port": 10201,

"host": "127.0.0.1",

"connectionType": "tls",

"connectionName": "Connection to node2",

"proxy": {

"address": "<proxy address>"

"user":"<optional proxy user>"

"pass":"<optional proxy password>"

},

"password": "<SECRET STRING>"

}

],

"netConf": {

"clientId": "node1",

"networkMapping": {

// send all *google* domain requests through node2

"*google*": "node2",

//if not captured with prev rules - execute locally

"*": "local"

}

},

"proxy": null,

"numConnsPerTether": 10

}

Potential Uses:

Stay connected to home equipment securely & without port mapping

Seamlessly RDP/VNC into multiple networks for remote support

Create secure agent connections from customer sites to cloud services

Bridge network gaps without help from your IT department

Stay connected to work without using a VPN

Use as a custom VPN to spoof your origin, protect your privacy and gain access to location based services

Expose on-premise webservers to potential customers or cloud testing farms through a socks5 proxy and some relays

Security features:

Inter-node connections (tethers) are TLS encrypted

Socks5 connections can be password protected (although not encrypted)

Socks5 connections can be restricted to accept only from localhost

Relay Server Authentication (Client has a password in the server config)

Isn’t Teleport just another VPN?

I have been pondering this same question for some time now: VPN, Tunneling and Socks5 have been around for years, has this idea been done before? well, it turns out that there are a ton of similar stuff out there: OpenVPN, BadVPN & Brook just to name a few, but each is different in some essential aspect. But VPNs are essentially point to point tunnels bringing you into a network via an encrypted channel, as for Teleport:

Teleporter uses multiplexing over multiple TCP channels per tunnel , Most VPNs operate on a low network layer, others (like OpenVPN) rely on UDP as their main transport to avoid the Head of Line problems, there are implementations that support TCP tunneling, but use a single TCP connections and regard this a bad solution to be used in specific cases. TCP support enables tunneling through most corporate environment restrictions that are based on allowing only TCP on port 80/443 or using an HTTP Proxy, and using multiple connections to do so avoids blocking browser connections behind unacknoleged or lost TCP packets.

, Most VPNs operate on a low network layer, others (like OpenVPN) rely on UDP as their main transport to avoid the Head of Line problems, there are implementations that support TCP tunneling, but use a single TCP connections and regard this a bad solution to be used in specific cases. TCP support enables tunneling through most corporate environment restrictions that are based on allowing only TCP on port 80/443 or using an HTTP Proxy, and using multiple connections to do so avoids blocking browser connections behind unacknoleged or lost TCP packets. Teleporter only relays requests for specified addresses, it creates an extremely split tunnel, giving the user full control over routing, this means that most of the requests can be handled locally, without lags or network costs. These specific address are your remote places (e.g. home), or addresses blocked by your work network (e.g: box.com, thepiratebay, etc.) there is almost no performance penalty for traffic that is executed locally and a small performance payment for sites that were never in your reach, allowing for home access without messy port mappings that expose your home machines to attackers on the public internet. Socks5 doesn’t use multiplexing, and is also unencrypted, which means no handshake delays or encryption overhead for local traffic.

it creates an extremely split tunnel, giving the user full control over routing, this means that most of the requests can be handled locally, without lags or network costs. These specific address are your remote places (e.g. home), or addresses blocked by your work network (e.g: box.com, thepiratebay, etc.) there is almost no performance penalty for traffic that is executed locally and a small performance payment for sites that were never in your reach, allowing for home access without messy port mappings that expose your home machines to attackers on the public internet. Socks5 doesn’t use multiplexing, and is also unencrypted, which means no handshake delays or encryption overhead for local traffic. Teleporter easily creates multi hop networks which are not typical of VPN setups

which are not typical of VPN setups Teleporter is very easy to set up: just by changing several lines in a JSON file, running a single binary on several machines you can create a distributed network for yourself, set your browser or OS proxy to run via the local socks5 proxy, and you are done.

just by changing several lines in a JSON file, running a single binary on several machines you can create a distributed network for yourself, set your browser or OS proxy to run via the local socks5 proxy, and you are done. Teleporter is built in Go so it easily compiles to all major OS flavors.

so it easily compiles to all major OS flavors. In Teleporter (future feature), rewrite rules can be used to have a “CNAME” like: home.com for your home machine address.

How does it work?

Each Teleport node has the ability to create relay servers, socks5 servers, and to connect a connection-bundle (A.K.A. Tether) to other relay nodes, a Tether holds multiple TCP connections, each capable of TCP multiplexing. Each such tether is bi-directional, allowing requests to be initiated by either side.

The Full Story

Our original solution was based on NGrok 1.0, with an added http-proxy server on the browser machine, which meant that for each browser connection, we were creating a connection from the proxy to the tunnel-server, from the tunnel-client to the tunnel-server and from the tunnel-client to the web-server. after we built it and started working on connection caching and reuse, I thought “this can be better solved by multiplexing”, but when digging into the subject, I found out that since TCP requires an ACK for each packet, it tends to get stuck (the head of line problem), and that UDP should be used for such solutions, but UDP will not pass out of most corporate setups, and never pass over a WAF into an AWS farm… I decided to drop the subject, but some corner of my mind kept nagging at me that there should be a better way.. So I created Teleporter as side project to better explore the possibilities.