open source · flexaccessdev

Reach private networks without opening a single port.

Tunneling and VPN utilities built on iroh, where the client dials the server by a stable cryptographic identity — NAT traversal and relay fallback built in, everything end-to-end encrypted, every client admitted by its own Ed25519 key. The server needs no public IP, no inbound port, no port forwarding.

Available on
  • CLI
  • Linux
  • macOS
  • Windows
  • iOS
  • Android
  • No inbound ports

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

  • NAT traversal built in

    Direct paths are hole-punched through NAT and CGNAT; an encrypted relay carries traffic when a direct path can't be found, and a connection can start relayed and upgrade to direct mid-life. Bring your own relays and nothing touches public infrastructure.

  • 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 access.

The tools

flexaccess.dev/ezvpn

ezvpn

The easy-setup VPN for reaching private networks.

  • IP layer
  • root required

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.

Available on
  • CLI
  • Linux
  • macOS
  • Windows
  • iOS
  • Android

flexaccess.dev/flextunnel

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.

Available on
  • CLI
  • Linux
  • macOS
  • Windows
  • iOS

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.

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
# 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

Which one do I want?

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
PhonesiOS and Android appsiOS app — browser and port forwards, no VPN profile
Alongside another VPNiOS allows only one active VPN at a timeYes — it isn't a VPN

Under the hood

Both tools share one transport foundation and one key format, kept in their own repos so they never drift apart.

  • shared
    flexaccess-keys

    The shared Ed25519 key format and CLI — generate-auth-key / show-auth-key — used by both tools.

  • shared
    iroh-common-architecture

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