When you create a “virtual private network” the “exit” of that network is a physical node with a legal jurisdiction. That jurisdiction determines who can compel disclosure of your traffic metadata, under what authority, and whether anyone is required to tell you it happened. Choosing the right jurisdiction is the first security decision of any “private” network. Everything else depends on it.

eisengarn Intro

After hearing many people ask what they should do about the crisis of fraud in the VPN provider market (many of them apparently are cosmetic shells that trace back to the same hedge fund, or an anti-privacy politically ambitious CEO), I created eisengarn. Of all the options I saw presented, none seemed to offer the simplest answer of all.

I didn’t see any reason for something to be magic or marketed when the concepts of private networking are as old as the Internet itself. So I put together the most simple solution I could, and not simpler: a personal WireGuard VPN provisioner written in Go.

I like to sing Rudy Toombs’ “one binary, one cloud, one protocol (VPN)” to the tune of one bourbon, one scotch, one beer. Your musical tastes may differ, but the point is the simplicity and transparency that brings integrity.

One scotch, one bourbon, one beer

One scotch, one bourbon, one beer

Please mister bartender,
listen here

I ain’t here for trouble,
so have no fear

One scotch, one bourbon, one beer

You run one command and get a hardened WireGuard exit node on the Hetzner Cloud, locked by code that only allows EU jurisdiction datacenters: Nuremberg, Falkenstein, Helsinki.

The name is awkward to say, but it’s a real German textile term for “iron yarn”, which means paraffin-treated cotton thread. It’s perhaps known best as Bauhaus tubular-steel chair webbing (Stam, Breuer). It has strong, thin, functional, engineered attributes. What’s not to like? The metaphor is a simple purpose-fit physical thing to make your internet more trusted.

Jurisdiction Details

Hetzner is a German company, thus under German and EU data protection law. The GDPR applies. The server you provision sits in a known legal regime with strong data-protection statute. That’s why eisengarn hardcodes the location, giving an easy and reliable jurisdictional boundary.

The code is open on Codeberg, a German non-profit running Forgejo. The DNS resolvers are Quad9, a Swiss foundation with a no-source-IP-logging policy, and DNS.SB, operated in Germany, both over DNS-over-TLS.

The cloud, code, and DNS all remain within EU jurisdiction, unlike the American services known to be heavily monitored by Trump for loyalty, and subject to being disabled immediately without warning.

Ms. Prost was at home, standing in her kitchen, when the call came informing she was being sanctioned. It wasn’t a complete surprise, given that many of her colleagues had already been sanctioned, she said during an interview…. Within hours, she said, she had received a message from Amazon canceling her accounts. Before long, Google & her banks got in touch. Over the following days, credit cards ceased to work.

Design Details

WireGuard keypairs are generated server-side on first boot; the private key stays on the server and is read directly into the WireGuard config there. Client keypairs are generated locally on your machine; only the public key crosses the wire. Every key artifact is written atomically: create temp file, chmod 0600, rename into place.

SSH authentication is agent-only. Your private key stays in ssh-agent, protected by your passphrase, and eisengarn prints which key it selected so you can confirm. Host-key pinning is trust-on-first-use and fails closed: a changed host key aborts the connection.

IPv6 is dual-stacked with NAT66, so both address families route through the tunnel and exit in the EU. DNS runs through unbound, listening only on the tunnel interface, forwarding over TLS. The firewall is scoped to OpenSSH and WireGuard’s UDP port; the resolver is reachable solely from inside the tunnel.

Threat Details

eisengarn, if not already apparent, is a jurisdiction tool. You control the exit node. You choose the legal regime your traffic lands in. The security properties are visible in code rather than in a sketchy hedge-fund VPN flogging “personality type” marketing.

The README spells out exactly what the trust boundaries are: your Hetzner account ties the server to your identity, the exit IP is stable and yours, and traffic past the exit is as encrypted as it was to begin with. Honest documentation so you know exactly where the boundaries are should help you make real decisions about your threats.

Workflow Details

It’s in Go, statically compiled, CGO disabled. Clone it from Codeberg, make build, and this is the entire workflow:

eisengarn up — provisions a locked-down Ubuntu 24.04 server in the EU datacenter you chose, configures WireGuard and the DNS resolver, pins the host key, writes local state.

eisengarn add laptop — generates a keypair on your machine, sends only the public key to the server, writes laptop.conf and a scannable laptop.png QR code. Import the conf into WireGuard on the device. Scan the QR on a phone.

eisengarn verify — runs live checks against the server: tunnel up, unbound active, firewall scoped, DNS resolver unreachable from the public internet.

eisengarn list — shows your devices, reconciled against the live server.

eisengarn down — destroys the server and stops the bill.

A cpx22 at Hetzner runs only a few euros a month, perhaps less than your VPN service charges. The server is persistent, meaning you can provision once, add devices over time, and eisengarn down when you’re done. A down command immediately destroys the complete server.

v0.1.0 was just tagged, under a MIT license.

Enjoy, and stay safe out there.