A full-tunnel virtual private network (VPN) sends a remote device’s traffic through the organization’s VPN gateway by default. A split-tunnel VPN sends some traffic through that gateway and some outside it. Choose the design by deciding where each application’s security controls must operate, then evaluate the performance of those paths.
For an IT manager supporting remote employees, a useful third choice is available: keep the VPN as the default and allow a small set of approved cloud-service destinations to connect directly. That is a different commitment from sending all internet browsing outside the VPN.
Start with one employee’s working day
Consider a hypothetical employee using a managed laptop at home. They enter orders in a private application at headquarters, join Microsoft Teams meetings, and visit supplier websites. The company currently sends all three through its VPN and applies web policy at headquarters.
Meetings have become unreliable. Before changing routing, the IT team should establish whether the VPN path contributes to the problem; home Wi-Fi, the internet connection, and the application can also affect the experience. Suppose an approved comparison identifies the central route as a bottleneck. The design question becomes which traffic to move, while preserving the company’s other requirements.
Network Box USA’s Managed Unified Threat Management (UTM+) service brings VPN, firewall, intrusion prevention, traffic policy, logging, updates, and operational support together. That makes the gateway’s routing and policy responsibilities part of the service-design discussion. The proposed client, supported routing controls, and ownership of changes still need to be confirmed for the actual deployment.
Compare three routing choices
Keep full tunneling
The private order system, cloud meetings, and supplier browsing continue through the gateway. This suits a design that relies on central enforcement for those flows, provided the path has adequate capacity and acceptable application performance. NIST’s IPsec VPN guide explains how traffic can be decrypted at the VPN gateway, passed to the organization’s firewall, and then forwarded to the internet.
The tradeoff is that internet-bound work takes the central route too. If that route is the measured constraint, retaining it means addressing that constraint.
Allow a few cloud-service exceptions
The order application and ordinary browsing keep their existing paths. Only defined cloud destinations bypass the VPN. Microsoft’s Microsoft 365 split-tunnel guidance recommends a tightly scoped approach around its documented Optimize category of core-service destinations, with appropriate security controls supplied by the service and other layers.
For the hypothetical company, this is the first alternative worth evaluating: it targets the identified meeting problem without also changing supplier browsing. Use the provider’s current endpoint guidance; “allow Microsoft” is too vague a routing instruction. This Microsoft example does not establish that a particular Network Box USA client or deployment supports the same configuration.
Send only private-company traffic through the VPN
The order system stays in the tunnel, while meetings and supplier browsing use the local internet path. Microsoft distinguishes this selective-tunnel model from a forced tunnel with a few exceptions. The change now includes general web access, so the company needs a deliberate replacement for any web controls it previously applied only at headquarters. NIST also cautions that a remote host’s direct internet connection can create an attack path toward corporate resources. Restrict VPN access to the services the employee needs and retain endpoint protection whichever routing model you choose.
Network Box USA’s Managed Secure Web Gateway (SWG) provides web policy, HTTPS inspection, malware defense, and reporting for office, remote, and roaming users. An agreed SWG path can supply those web controls without routing browsing through headquarters. Its actual deployment path must be established; traffic excluded from the VPN is not automatically covered by another service.
Turn the choice into a precise change request
For this hypothetical company, the limited-exception proposal could read:
Keep the private order application and general web browsing on their current managed paths. Evaluate direct routing only for the documented Microsoft 365 destinations needed to address the meeting problem. Retain the required identity, endpoint, and cloud-service controls. Expand the exception only after separately reviewing the additional traffic and its protection.
This is a proposed design brief, not a device configuration. It gives the network operator a defined change to assess and the business owner a clear boundary to approve. If the company instead wants all browsing to go direct, it should commission that wider security design explicitly.
Routing outside a VPN does not necessarily mean plaintext: HTTPS can still encrypt an application connection. It does mean that the corporate VPN gateway no longer supplies its protections to that flow. Keep transport encryption, web inspection, and access permissions distinct.
Validate the employee’s actual work
On an approved pilot device, verify the order transaction, a representative meeting, and supplier browsing. Confirm the intended routes and required policy behavior, then compare application performance. Microsoft’s Windows routing documentation shows why effective routes matter: more-specific routes can take precedence over a VPN default.
Include Internet Protocol versions 4 and 6 (IPv4 and IPv6) where used, and check the Domain Name System (DNS) resolver that turns application names into addresses. Our DNS encryption and filtering explanation covers that separate policy decision. Agree what users can access when the tunnel is unavailable and who maintains changing cloud destinations.
The customer’s identity, endpoint, and application teams retain their respective controls; the managed gateway team operates the agreed network scope. To compare these VPN designs, contact our team with your remote users’ application destinations, current security paths, and the business problem the routing change should solve.