How to Create a VPN for Controlled Remote Access
Building an organization-managed VPN requires more than a client application. It requires a reachable gateway, authenticated users or devices, routes to approved resources, DNS, and rules that deny access outside the intended scope. The service is ready for use only after those paths and restrictions have been tested.
Define a Small Access Boundary
Consider a field team that needs a web application at 10.20.0.10 over HTTPS and an internal DNS server at 10.20.0.53. The office network is 10.20.0.0/24; the VPN client pool is 10.30.0.0/24. The gateway has an internal interface on the office network and a public address or DNS name reachable by clients. These addresses are illustrative.
Before deciding how to create a VPN, identify the users, devices, destination addresses, and ports that need access. Select a client pool that does not overlap the office network or the remote networks expected in use. If a user’s home network overlaps an internal destination, a device may send traffic to the local network instead of the tunnel; choose a different internal range or plan a specific remedy for that conflict.
Configure the Gateway and Identity
One implementation is a routed OpenVPN Community server. OpenVPN’s configuration guide describes a TUN interface and a client address pool; the example here substitutes the pool above. Deploying the VPN starts with installing and maintaining the gateway on a controlled host; permit the selected VPN listener through the perimeter firewall, and forward that port to the gateway if it sits behind network address translation (NAT).
Create a certificate authority and separate server and client certificates. Keep the authority’s private key protected, issue a distinct client credential per device or user, and configure clients to verify the server’s identity. OpenVPN’s certificate guide describes mutual certificate authentication. Distribute each profile and private key through a controlled channel; a shared profile makes individual removal harder.
To establish the VPN service, configure the gateway to allocate client addresses and forward permitted traffic. Provide a return route on the office router for 10.30.0.0/24 via the gateway’s internal address. Alternatively, apply source NAT at the gateway when direct return routing is unavailable; this changes the source address seen by the application and affects per-client attribution.
Route and Restrict Traffic
For the example, send a route to 10.20.0.0/24 to clients and keep ordinary internet traffic outside the tunnel. Setting up the VPN also means configuring the client to use the internal DNS server for the required internal names, and verifying the behavior on each supported client platform. A route merely directs packets; it does not grant permission.
At the gateway and relevant internal firewalls, allow the client pool to reach 10.20.0.10 on TCP 443 and the DNS server on UDP and TCP port 53. Deny other office destinations and client-to-client access unless explicitly needed. Ensure that replies can return to the client pool. Log connection and policy events in line with the organization’s retention policy, without recording private keys.
Creating a private VPN also requires an operating process. Assign an owner for gateway updates, certificate expiry, configuration backups, and access removal. When a device is lost or a user leaves, revoke its certificate and update the gateway’s revocation list. OpenVPN’s revocation guidance explains that new connections are checked against the list; an existing session may also need to be disconnected.
Verify Before Rollout
A test profile shows how to create a VPN that enforces the intended boundary, not merely one that connects. Perform these checks from a network outside the office:
- Connect: authenticate and confirm that the client receives an address from the intended pool. Test a failed or revoked credential as well.
- Allow: resolve the application’s internal name and load it over HTTPS; verify that replies return through the gateway.
- Deny: attempt an unrelated internal host and port and confirm the firewall blocks them, even though the client has a route to the subnet.
- Revoke: disconnect the test client, revoke its certificate, update the list, and confirm that a new connection is rejected. Terminate any active session when immediate removal is required.