How WireHop works

The short version

A control plane, a hub, and a router at each site

WireHop gives organization members identity-aware access to selected IPv4 networks. The dashboard manages people, gateways, routes, and policies. A WireHop hub terminates users’ WireGuard tunnels and enforces access decisions. A small subnet-router agent at each protected site forwards permitted traffic into that site’s network.

WireHop desktop client
        │
        │ WireGuard tunnel over UDP
        ▼
Regional WireHop hub
  terminates tunnel · checks policy
        │
        │ authenticated relay WebSocket
        ▼
Subnet-router agent at the site
  wrtun0 · Linux forwarding
        │
        ▼
Protected IPv4 network

First setup

Set up an organization

1. Create the organization

   The person who creates it becomes its owner. Invite colleagues and give each member only the organization role and gateway access they need.

2. Register a subnet router

   Add a gateway for the private site and list the IPv4 CIDR ranges it is allowed to reach, for example 10.20.0.0/16. These routes define the network boundary for that gateway.

3. Install the site agent

   Use Install router in the dashboard and run the generated setup script on a supported Linux host that can reach the protected network. The agent creates wrtun0 and opens an outbound authenticated WebSocket to its relay. The protected site does not need an inbound WireGuard port.

4. Assign access and policies

   Assign members to the gateway directly. Optionally organize members into groups, label gateways, and add allow or deny policies for narrower access.

5. Connect from the desktop app

   A member signs in, creates or selects a connection, and connects. WireHop issues a WireGuard peer configuration with the selected routes; its private key is returned once and is not stored by WireHop.

Setup references: download the desktop app and read the published plan details.

A connection, step by step

How traffic moves

1. The client selects a protected route

   The connection profile lists approved destinations as WireGuard AllowedIPs. Traffic for those IP ranges enters the tunnel; unrelated traffic stays on the device’s normal network unless an administrator has configured an exit-node route.

2. The hub receives and evaluates the packet

   The client sends encrypted WireGuard traffic to the hub’s public UDP endpoint. The hub decrypts it, identifies the peer and destination, checks the route and access policies, then either drops the packet or forwards it.

3. The relay delivers it to the selected site

   The hub sends the allowed IP packet over its authenticated relay session. The relay forwards it to the authenticated agent registered for that gateway.

4. The site router reaches the private network

   The agent writes the packet to wrtun0. Linux forwards it to the destination and applies scoped source NAT so the protected network can return the response without a new inbound route to the WireHop client.

5. The response follows the reverse path

   The agent sends the response through the relay to the hub. The hub writes it to the client tunnel, and WireGuard encrypts it for delivery back to the device.

Identity plus network policy

How access is decided

Three checks combine to decide what a connection can reach:

Policy decision order

1. A matching deny policy blocks the packet, even if an allow policy also matches.
2. Otherwise, a matching allow policy permits it.
3. If no policy matches, the organization’s access mode decides.

Organizations currently start in ALLOW_ALL mode, which preserves access unless a deny policy matches. An owner or admin can choose DENY_BY_DEFAULT so packets must match an allow policy. Policy changes are applied by the hub to traffic, not just reflected as dashboard settings.

Supported posture checks are limited; for example, the source-CIDR check uses the client’s observed public endpoint IP. It is not a check of device health, antivirus, operating-system version, or running processes.

Routes and locations

Gateways and regions

A gateway represents a subnet router and the protected networks behind it. A hub is the public WireGuard endpoint for clients. The relay is the bridge between that hub and the site router. Each gateway is assigned to a region; its hub and router agent must use the same regional relay.

• Split routes: clients send only selected protected IP ranges through WireHop by default.
• Regional selection: when multiple eligible regions are available, the desktop app measures latency and selects a suitable fast region. Moving a peer to another hub requires it to reconnect with the target hub’s configuration.
• Advanced routes: admins can configure domain routes and exit-node gateways. Domain names resolve to IPv4 addresses when a client route is issued, so a changed address may require a refreshed client configuration. Exit nodes can carry a default route; they must be explicitly configured and assigned, and a reachable DNS resolver must be selected to avoid DNS leaks.

Region selection is not seamless high availability. A relay instance routes only to agents connected to that instance, and WireHop does not provide transparent cross- region relay failover.

People, accounts, and ongoing access

Identity and lifecycle

Dashboard identity and network identity are connected but separate: a person signs in to WireHop, while each active device connection is represented by a WireGuard peer. Social sign-in buttons are available when configured. Corporate SSO appears on the sign-in page; it is available to Business and Enterprise organizations and succeeds only when the organization has an enabled provider and the member is correctly bound to it.

Owner

Controls organization settings, members, gateways, and billing.

Admin

Manages the organization’s team, gateways, and access configuration.

Member

Uses the gateways and routes assigned to their membership.

Contractor

Uses assigned gateways with additional route and time limits.

Connections can expire or be revoked. The worker processes expirations, and the hub regularly reconciles the peers and routes it should allow. Suspending a user revokes their sessions and removes their active peers. Suspending an organization blocks its web operations, disconnects its routers, and removes its peers and routes; reactivation can restore service without deleting its records.

Billing entitlements are enforced separately from administrative suspension. A plan state can restrict resources, but changing a plan does not undo an administrative suspension.

Trials, plans, and access

Plans and entitlement

New organizations start with a 14-day Business trial and do not need a card to begin. When the trial ends, an organization without an active paid subscription moves to the Free plan. Free supports up to three retained members, including the owner, and one gateway. The owner can choose which eligible members and gateway keep network access. If no choice is recorded, WireHop retains the owner, the two earliest-created active members, and the earliest-created gateway. Other resources remain stored but cannot carry traffic. Existing grandfathered organizations keep their existing billing state.

WireHop checks plan entitlements in the control plane, relay, and hub. A dashboard button alone does not grant network access, and plan restrictions do not delete the organization’s data. Paid subscriptions are not currently enabled for live charges. See the published plan details for current pricing and included features.

Know the boundaries

Security and current limits

• No inbound site port: the subnet router connects outward to its relay. The hub does need a public WireGuard UDP endpoint (normally UDP 51820), and users need network access to that endpoint.
• Private keys: the client private WireGuard key is returned once and is not stored in the database. Generated installer commands and pairing tokens are sensitive and should be handled securely.
• IPv4 data plane: protected network traffic and policy enforcement currently support IPv4, not IPv6.
• Linux subnet router: the packaged agent targets Linux amd64 and needs TUN access plus permission to configure forwarding and firewall rules.
• Regional boundaries: each hub and its assigned gateway agents must use the same relay instance. There is no cross-instance forwarding or automatic transparent relay failover.