u/klstew

For many years I have honed a little homelab which I accessed it via standard Wireguard VPN connection. Some months ago, I had this idea that my homelab should have zero listening ports on the public internet, for the fact that my router was not being kept up to date with all latest patches. I navigated through headscale/tailscale, cloudflare, etc, however I wanted something incredibly lightweight, that could run on my OpenWrt router.

So I built a CLI tool that reverses the connection direction of the hosting server, primarily to create an outbound connection, requiring no listening ports on my homelab gateway. These connection (the server and all clients) needed a rendezvous point where their outbound connections would be tied. I also wanted to avoid issues like complex TLS termination, authentication and possible DDoS attacks on the relay, so it was decided to use WebSockets rather than UDP connections. This provided the possibility to host the relay on the web behind reverse proxies, offloading all other complexities to the battle hardened nginx, while keeping my codebase tiny. Hence BastionRoute was born.

BastionRoute tries to solve one thing and one thing only. To provide a means for a UDP server to initiated outbound connections towards a Websocket relay. In doing so, BastionRoute remains payload agnostic, as long as UDP traffic is flowing, it does not care if its Wireguard traffic or any other software. BastionRoute does not require Wireguard keys to operate, in fact for a Wireguard perspective, only the connection configuration changes, nothing else. Wireguard encryption remains end-to-end. In doing so the relay becomes a blind transport broker.

So as a general problem I tried to solve with BastionRoute is that a minimal, potentially untrusted forwarding fabric (essentially the relay) can provide reachability for an end-to-end secure networking protocol without becoming part of that protocol's cryptographic trust boundary.

I loved working on this project and I wanted to share it with the community. Any feedback is much appreciated.

More info on bastionroute.io

For many years I have honed a little homelab which I accessed it via standard Wireguard VPN connection. Some months ago, I had this idea that my homelab should have zero listening ports on the public internet, for the fact that my router was not being kept up to date with all latest patches. I navigated through headscale/tailscale, cloudflare, etc, however I wanted something incredibly lightweight, that could run on my OpenWrt router.

So I built a CLI tool that reverses the connection direction of the hosting server, primarily to create an outbound connection, requiring no listening ports on my homelab gateway. These connection (the server and all clients) needed a rendezvous point where their outbound connections would be tied. I also wanted to avoid issues like complex TLS termination, authentication and possible DDoS attacks on the relay, so it was decided to use WebSockets rather than UDP connections. This provided the possibility to host the relay on the web behind reverse proxies, offloading all other complexities to the battle hardened nginx, while keeping my codebase tiny. Hence BastionRoute was born.

BastionRoute tries to solve one thing and one thing only. To provide a means for a UDP server to initiated outbound connections towards a Websocket relay. In doing so, BastionRoute remains payload agnostic, as long as UDP traffic is flowing, it does not care if its Wireguard traffic or any other software. BastionRoute does not require Wireguard keys to operate, in fact for a Wireguard perspective, only the connection configuration changes, nothing else. Wireguard encryption remains end-to-end. In doing so the relay becomes a blind transport broker.

So as a general problem I tried to solve with BastionRoute is that a minimal, potentially untrusted forwarding fabric (essentially the relay) can provide reachability for an end-to-end secure networking protocol without becoming part of that protocol's cryptographic trust boundary.

I loved working on this project and I wanted to share it with the community. Any feedback is much appreciated.

More info on bastionroute.io

Hey everyone,

​I wanted to share an open-source transport tool I’ve been building in Go to solve a rigid infrastructure security goal: How do you safely maintain remote access to localized real-time resources (like native WireGuard) while enforcing a strict zero-inbound listening port policy on your edge firewall? ​I wanted something completely stateless and invisible to the outside world, so I wrote BastionRoute.

​ ​Instead of a traditional client-server proxy topology, BastionRoute uses a decoupled model. Both your isolated server shim and your remote client shim initiate standard outbound Layer-7 connections to an external, transient relay broker room.
Because both nodes establish standard outbound pipes over HTTPS/WebSockets (Port 443), your home gateway requires exactly zero open inbound ports. Your network edge remains entirely dark to Nmap or Shodan scans.

​Emulating "UDP Physics" Over TCP ​The classic issue with wrapping real-time UDP inside stateful TCP is Head-of-Line blocking (TCP Meltdown). When a packet drops, TCP stalls the entire pipeline to retransmit, introducing devastating latency spikes that break VPN handshakes. ​BastionRoute’s concurrent data engine fixes this by leveraging non-blocking Go channel selectors. By explicitly dropping frames at the application layer the moment congestion is encountered, the stateful WebSocket transport perfectly mimics real-world, non-blocking UDP physics. If a remote link experiences jitter, the queue never backs up, keeping interactive streams fluid and lag-free.

BastionRoute acts strictly as low-level digital plumbing. It is entirely payload-agnostic and does not handle user management or internal cryptographic key generation. It assumes you are running a robust protocol inside it (like WireGuard), so its attack surface is incredibly small. ​The engine compiles into a tiny, zero-dependency binary (<8MB) capable of running on low-resource hardware like OpenWrt gateways. ​The project is fully open-source and ready to be tested or torn apart :) ​

https://github.com/klauscam/BastionRoute ​