A business VPN can carry traffic between a remote device and an organization, or between networks at different sites. Choose the access approach by the applications people need, the devices they use and the permissions you can enforce. Then test the complete working path, including removal of access.
Describe the access requirement
List who needs access, from which devices and locations, to which applications or network services. Separate ordinary employee work, contractor access and privileged administration. Record required hours, expected concurrent use and the consequences of losing connectivity.
A remote-access VPN connects a user device through a gateway. A site-to-site VPN connects networks, usually through gateways at each end. Application-specific access can expose selected applications through an intermediary without giving the same broad network reach. Compatibility and policy determine which approach fits a particular workload.
On a narrow screen, swipe the table or focus it and use the arrow keys.
| Need | Approach to investigate | Questions to resolve |
|---|---|---|
| Staff using several internal network services | Managed remote-access VPN. | Which destinations, routes and protocols will each group reach? |
| A branch office reaching another site | Site-to-site VPN. | Which subnets communicate, and how are overlapping addresses handled? |
| Users needing selected compatible applications | Application-specific access. | Can it enforce identity/device requirements and support every needed function? |
| Technicians administering critical systems | A separately controlled administrative access path. | How are elevated rights, session evidence and time-limited access managed? |
Test legacy applications early: a browser login alone may not satisfy a program that depends on particular network protocols, name resolution or background connections. Include file transfers, printing or device access only when the business actually requires them.
Evaluate the whole access path
NIST SP 800-46 Revision 2 treats remote access as a combination of client devices, access technology and policy. Use it as a security-planning reference, and use current official documentation for the exact product and version. A protected tunnel still depends on endpoint health, permissions and operational maintenance.
Require supported software, a named owner for gateway and client updates, suitable authentication and a way to review access. Keep administrative privileges separate from ordinary use. Record how contractor access expires and what happens when a device is lost.
NIST's Zero Trust Architecture focuses on users, assets and resources, with authentication and authorization before access to a resource. That gives buyers a useful question: what permits this person and device to reach this application? A product label alone does not answer it.
Clarify traffic routing. With split tunneling, selected traffic goes through the organizational connection while other traffic uses a different path. Sending all traffic through the tunnel changes bandwidth, inspection and failure dependencies. Have the responsible team document the intended policy and verify DNS, routes and access under it.
Test what works and what stays restricted
- Record the configuration. Capture client/gateway versions, account role, approved device state and intended routing without exposing secrets.
- Run representative work. Include normal use and the agreed volume of simultaneous users.
- Test interruption and recovery. Observe what happens when connectivity drops and whether applications leave incomplete or duplicated work.
- Check boundaries and evidence. Use authorized checks for allowed and restricted resources; verify useful logs and support visibility.
- Test access removal. Record timing and behavior for new and established sessions, devices and credentials as applicable.
Diagnose the failing layer
If a connection fails, first identify the last successful stage. Can the device reach the internet and the gateway? Does authentication complete? Is the intended route present? Can the application name be resolved? Does the application accept the user's permissions? Keep these observations distinct so a support team can investigate the relevant layer.
If a tunnel is connected but one application fails, collect the application error, time, affected account role and whether other permitted resources work. If local and remote networks use overlapping address ranges, flag that to the network administrator. For intermittent or slow behavior, compare the same task, connection and time period before drawing conclusions.
Use approved support procedures. Avoid disabling authentication, broadening access or changing routing simply to make a test pass. Record the fault, intended change and rollback plan so a qualified administrator can correct the cause.
Keep the service supportable
Document who maintains clients and gateways, handles certificates and account recovery, responds to alerts and supports users outside office hours. Rehearse the loss of an access component and agree an operational fallback that fits the business.
Use the remote-access requirements and acceptance worksheet for a pilot or provider discussion. Retest after significant changes to the gateway, identity service, client, routing or application. Keep evidence of revoked access and unresolved exceptions with the service records.