sish VS iodine

sish uses ssh tunneling that you can read about in their docs: https://ssi.sh/

Tunneling services can be considered as a solution in some cases. Services like ngrok, frp, localtunnel and sish create a public endpoint that tunnels communication to your local endpoint via a tunnel client.

My favourite one is https://github.com/antoniomika/sish

It uses SSH as the method of opening the remote tunnel to the public server.

Why not forget about Cloudflare and a VPN but get a 3 euro Hetzner server and install https://github.com/antoniomika/sish for dynamic DNS through SSH + Traefik with a DNS resolver and have yourself a wildcard certificate. This way you can host any service from home as long as you run a port forwarding service through SSH with a one liner on Ubuntu. Better yet make an alpine docker image with a command to route traffic to your local service for even more isolation. 😘

Personally I’ve been using sish[1] recently, lots of ngrok alternatives out there now, especially as the pricing went a bit weird

[1] https://github.com/antoniomika/sish

i used to use a similar tool called inlets but they removed the open licensing. i now self host a sish server (https://github.com/antoniomika/sish) which also uses ssh for the reverse tunnel client. so much simpler!

- Sish : Because I don't want to pay for ngrok anymore (https://github.com/antoniomika/sish)

They could create a tunneled connection. Take a look at ngrok.io or ssi.sh

Reminds me of using https://code.kryo.se/iodine/ ( DNS tunnel ) and a empty prepaid card...

Obligatory dns tunnel software for exfil. It is super noisy if you do dns querylogging, so I'd not use it for anything major, but it is a fun research tool.

https://github.com/yarrick/iodine

It's worth noting that you (re) invented what iodine does: https://code.kryo.se/iodine/

(https://github.com/yarrick/iodine)

It’s slow, but it works and is a handy “last resort” tool.

While working in an environment where VPN connections were pretty much all blocked⁰ a friend of mine had success using https://guacamole.apache.org/ to access a remote machine¹. Not quite the same as a direct VPN connection but worth a try if nothing else functions, it looks enough like normal HTTPS traffic that he got away with it.

To keep your wireguard setup more as-is, you could try https://kirill888.github.io/notes/wireguard-via-websocket/ to tunnel that via a web server. In fact https://github.com/erebe/wstunnel which that uses could be used just as well with any other UDP based VPN.

I once tinkered with https://github.com/yarrick/iodine and successfully connected to resources over the wireless on a train, bypassing its traffic capture and sign-up requirement, so that might be an option, though I think fully blocking external DNS is more common now so this is less likely to work²³.

--

[0] practically only HTTP(S) permitted, not even SSH, DPI in use that detected just using SSH or OpenVPN over port 443

[1] NOTE: be careful breaching restrictions like this, you are at risk of an insta-sacking if discovered, or worse if operating in some securiry environments!

[2] and the latency when it does work is significant!

[3] and that much traffic over port 53 might get noticed by the heuristics of data exfiltration scanner, encouraging sysadmins to notice and implement a way to block it

There's also iodine, a C program that tunnels IPv4 packets over DNS. Useful for bypassing captive portals on wifi, since DNS usually isn't restricted.

https://github.com/yarrick/iodine

Regarding cloudflare DNS over HTTPS: It could be that it tries to server data encoded as JSON, which is impossible in JSON. Some control characters and bytes 128-255 cannot be represented as JSON strings.

A regular proxy on port 53 might work? Is it necessary to actually use DNS?

Otherwise there's https://github.com/yarrick/iodine

Well, you're really exhausting your options here (and possibly your IT department's patience). Iodine would still be an option, it creates a tunnel through DNS traffic. Nearly impossible to block/filter out but you shouldn't expect a lot of bandwidth. Try it out! Although if you're only going to use low-bandwidth applications through the tunnel anyway you might as well use your own mobile data plan instead of your school's WLAN.