Stand up a roadwarrior gateway from the VPNGeek dashboard so individual users connect into your network — client pool, pushed routes and DNS, per-seat users, and split-tunnel choices.
A client-to-site VPN — sometimes called roadwarrior or remote-access — lets individual people connect into a network from a laptop or phone, wherever they are. Unlike a site-to-site tunnel that joins two fixed LANs, here each user gets an address from a shared pool and an identity you can grant or revoke on its own. This guide builds a remote-access gateway from the VPNGeek dashboard: you define the client pool, decide what routes and DNS to push, add a seat per person, and hand out a config or app profile they import once.
Before you start
Collect these before you create the gateway. The pool and route choices are easiest to set correctly up front.
- A VPNGeek plan that includes IPsec Gateways and enough seats for your team, plus dashboard admin access.
- A VPNGeek gateway appliance or VM installed on the network users will connect into, with a static public IP or DDNS hostname.
- UDP 500 and UDP 4500 reachable from the internet to that gateway.
- A client IP pool that does not overlap any LAN your users are ever on — this guide uses 10.99.0.0/24, deliberately outside the 10.20.0.0/16 office range.
- The internal DNS resolver address if you want clients to resolve internal hostnames.
1. Create a remote-access gateway
Open Gateways > Add gateway and choose Remote access (client-to-site) rather than site-to-site. Name it, set the public endpoint clients will dial, and select the protected network they should reach. Then deploy the bundle to the appliance exactly as for any gateway.
mode: remote-access
endpoint: 203.0.113.10 # public IP clients connect to
protected_net: 10.20.0.0/16 # the office network they reach
ike_version: 2 # IKEv2
encryption: aes-256
integrity: sha-256
pfs_group: 14
# then, on the appliance:
vpngeek enroll --token RA-XXXX-XXXX-XXXX
vpngeek deploy
vpngeek status # gateway ONLINE
2. Define the client IP pool
In the gateway's Client pool panel, set the range VPNGeek leases to connected users. Each active session takes one address; size the pool for peak concurrent users, not total headcount. Keep it clear of every LAN a user might be sitting on, or their local traffic will collide with the tunnel.
lease: per-session # address returned to pool on disconnect
3. Set the pushed routes and DNS
When a client connects, the gateway pushes the routes and resolvers it should use. This is where you choose split versus full tunnel. Split tunnel pushes only the office subnets, so a client's general internet traffic keeps going out its local link. Full tunnel pushes a default route, sending all the client's traffic through the office — useful for enforcing egress filtering, at the cost of backhauling every packet.
push_routes: 10.20.0.0/16
push_dns: 10.20.0.53 # internal resolver
dns_domain: corp.example # search domain for internal names
# Full tunnel — everything goes through the office instead:
# push_routes: 0.0.0.0/0
4. Add users and seats
Open the gateway's Users tab and add one entry per person. Each user consumes a seat and gets its own credentials — a certificate (recommended) or EAP username, plus an optional per-user pool reservation. Because identities are separate, you can disable one person without touching anyone else.
vpngeek user add alice --gateway team-ra --auth cert
vpngeek user add ravi --gateway team-ra --auth cert
vpngeek user list --gateway team-ra # shows seat + status per user
5. Distribute the client config or app profile
Each user has a Download profile action that produces everything their client needs — gateway address, their certificate, the crypto proposal, and the pushed routes/DNS baked in. Send it over a secure channel; the profile contains that user's private key. In the VPNGeek client app they import it once; on native IKEv2 clients it installs as a VPN configuration.
vpngeek user profile alice --gateway team-ra --out alice.vpngeek
# The profile bundles, per user:
# endpoint 203.0.113.10, IKEv2 / aes-256 / sha-256 / DH14
# client cert + key, pushed routes 10.20.0.0/16, DNS 10.20.0.53
6. Connect and verify
The user opens the VPNGeek client, selects the imported profile, and connects. Within a few seconds the dashboard Sessions view lists them with their leased pool address and live byte counters. Confirm they can reach an internal host, and — on a split tunnel — that ordinary internet traffic still leaves locally.
ip addr show vpngeek0 # leased address from 10.99.0.0/24
ping 10.20.0.10 # reach an office host
# split tunnel check — this should NOT go through the VPN:
# traceroute to a public site stays on the local link
Troubleshooting
Split vs full tunnel confusion
If users report the internet "feels slow" or geo-restricted after connecting, you almost certainly pushed 0.0.0.0/0 (full tunnel) when you meant split. Reset push_routes to just the office subnets in step 3. Conversely, if a full tunnel is required for compliance but internal-only sites still bypass it, confirm no more specific split route is also being pushed.
Per-user revocation
To cut off one person — lost laptop, departed employee — revoke that user; their certificate is added to the CRL and any live session is torn down at the next check. Everyone else stays connected. Never regenerate the gateway-wide credentials for a single user, as that forces the whole team to re-import.
vpngeek user disable ravi --gateway team-ra # temporary block, keeps the seat
Client connects but cannot resolve names
The tunnel is up but internal DNS was not pushed. Re-check push_dns and dns_domain in step 3; on split tunnels the client keeps using its local resolver for everything you did not push.
Pool exhausted
If new connections are refused while existing ones work, the client pool is full. Every concurrent session holds one address — widen 10.99.0.0/24 to a larger range, or free stale leases from the Sessions view.