open source · flexaccessdev

Reach private networks without opening a single port.

Tunneling and VPN utilities built on iroh. Clients dial the server by a stable cryptographic identity, so it needs no public IP, no inbound port, and no port forwarding — NAT traversal, relay fallback, and per-client keys are built in.

Available on
  • CLI
  • Linux
  • macOS
  • Windows
  • iOS
A client behind NAT reaches a server with no open port: the relay carries signalling and encrypted fallback traffic, and a hole-punched direct path carries the rest.relaysignalling · encrypted fallbackNAT / firewalldirect · hole-punchedQUIC · TLS 1.3your devicebehind NATyour serverno public IPno open port
  • No inbound ports

    The server needs no public IP, no open port, and no port forwarding. Clients dial a stable endpoint ID — itself an Ed25519 public key — instead of an address.

  • NAT traversal built in

    Direct paths are hole-punched through NAT and CGNAT. When none can be found, an encrypted relay carries the traffic, and a connection can upgrade from relayed to direct mid-life.

  • End-to-end encrypted

    Traffic rides QUIC with TLS 1.3 from client to server. Relays that forward it see only ciphertext and connection metadata — never plaintext.

  • Key-authenticated

    Every client signs in with its own Ed25519 key, listed ssh-style in the server's authorized-keys file. Whoever runs the server decides exactly who gets in.

the tools

Two tools, one transport

Same dial-by-identity connection, same keys, same relays. They differ in which layer they give you — and whether you need root to get it.

ezvpn

The easy-setup VPN for reaching private networks.

  • IP layer
  • needs root

Full IP routing to a private network — whole subnets, any protocol — with dynamic client addressing, per-client Ed25519 keys instead of certificates or PKI, and no inbound port to open or forward.

Pick it when
  • You want a whole subnet reachable — any protocol, transparently, through the routing table
  • You can run as root / Administrator on the client
  • You'd rather have a native VPN app on your Mac, iPhone, or Windows PC

flextunnel

The rootless split tunnel for private TCP services.

  • proxy layer
  • no root

Reach TCP services behind a server over a local SOCKS5 / HTTP proxy or forwarded ports — with server-side DNS, host aliases, server-to-server bridges for networks the server can't reach directly, a zero-config --quick mode, and no admin rights on either end.

Pick it when
  • You need specific TCP services — web UIs, SSH, RDP, databases — not a whole subnet
  • You can't get root or admin on the machine you're sitting at
  • You want it next to an existing VPN, or a five-minute throwaway tunnel

which one

Which one do I want?

Side by side, on the things that decide it.

You needReal IP routing — whole subnets, any protocolTCP access to specific services — web UIs, SSH, databases
PrivilegesRoot / Administrator to create the network interfaceNone, on either end
How apps connectTransparently, through the system routing tableThrough a local SOCKS5 / HTTP proxy or a forwarded port
AuthenticationPer-client Ed25519 key (flexaccess-keys)Per-client Ed25519 key (flexaccess-keys), or --quick with no keys at all
Desktop appsmacOS app as a signed .dmg, Windows app as an unsigned .msi — plus the CLImacOS / Windows tray app as unsigned .dmg / .msi — plus the CLI
PhonesiOS app, built from source under your own teamiOS app — browser and port forwards, no VPN profile; unsigned .ipa you sign yourself
Next to another VPNIt is a VPN — on iOS, only one can be active at a timeIt isn't a VPN, so there's nothing to switch off
Not forClient-to-client meshes, site-to-site links, anonymityUDP, or apps that can't use a proxy or a forwarded port

shared · flexaccess-keys

One key format for every FlexAccess tool.

Both tools authenticate clients with the same app-independent Ed25519 key format: a private key file you keep on the client, and one ed25519-pub: line per client in an ssh-style authorized-keys file on the server. flexaccess-keys is the small CLI that generates and inspects those keys — install it once and use it for ezvpn and flextunnel alike. The GUI apps generate the same keys in-app, so a phone or a Mac needs no CLI at all.

Linux / macOS
curl -sSL https://flexaccessdev.github.io/flexaccess-keys/install.sh | bash
Windows (PowerShell)
irm https://flexaccessdev.github.io/flexaccess-keys/install.ps1 | iex
flexaccess-keys on GitHub
generate · show · authorize
# on each client: generate a keypair, then print its public entry
flexaccess-keys generate-auth-key "alice laptop" -o client.key
flexaccess-keys show-auth-key --private-key-file client.key
#   → ed25519-pub:… alice laptop

# on the server: authorized_keys, one client per line
ed25519-pub:<public key> alice laptop
ed25519-pub:<public key> build server

under the hood

One foundation, kept in its own repos

Both tools share one transport crate and one key format, so they never drift apart. Point both ends at two or more relays you run yourself and nothing touches public infrastructure.

  • transport crateflexaccess-iroh

    The shared transport layer as code: relay configuration and the per-relay startup probe, the common endpoint builder, in-place home-relay failover for servers, and the endpoint-bound key authentication transcript. Its offline end-to-end suite proves failover against real relays, and a client can start while one relay is down. A fix lands here once and reaches every tool on its next tag bump.

  • key formatflexaccess-keys

    The shared Ed25519 key format — generate-auth-key / show-auth-key on the CLI — used by both tools, with the same library embedded in their GUI apps.

  • design notesiroh-common-architecture

    Design notes and operating guides for the transport layer: relays and address lookup, relay failover, NAT traversal by NAT type, and self-hosting your own relay.