Academic · By Ujitha Rodrigo ·
- Reviewed by
- OneAccess Technical Review
- Reviewed
- 4 July 2026
- Tested version
- UniFi Network 8.x interface family with OpenVPN remote access
Purpose
This article explains the decision behind full tunnel and split tunnel VPN designs for UniFi OpenVPN deployments. It is written for administrators who need to decide whether remote-user traffic should all pass through the office gateway or whether only private office traffic should use the VPN tunnel.
This is Part 01. It focuses on design, risks, expected behaviour, and checks before implementation. Configuration steps should be tested against your current UniFi Network version before use in production.
Tested context
- Platform family: UniFi gateways managed through UniFi Network
- VPN type: OpenVPN remote access
- Tested version: UniFi Network 8.x admin interface family
- Client type: OpenVPN-compatible remote-access client
Confirm the exact UniFi gateway model, firmware, and Network application version before applying any VPN change.
Prerequisites
- Administrator access to the UniFi Network console
- A backup of the current gateway configuration
- A known office LAN subnet, such as 192.168.0.0/24
- A list of internal systems remote users must access
- A test user and test device outside the office network
- Approval for the security model: full tunnel or split tunnel
Full tunnel and split tunnel explained
In a full tunnel VPN, all client traffic is routed through the VPN tunnel. That includes traffic to internal office systems and normal internet traffic. This can centralize inspection and logging, but it increases load on the office internet link and gateway.
In a split tunnel VPN, only selected private networks are routed through the tunnel. General internet traffic continues to use the user's local connection. This can improve performance and reduce gateway load, but the organization must understand what traffic is no longer inspected by the office firewall.
Example scenario
Assume an office uses a UniFi gateway with an internal LAN of 192.168.0.0/24. Remote staff need access to an ERP server inside that LAN. They do not need all internet browsing to pass through the office.
In that scenario, split tunneling may be appropriate if the business accepts that only ERP and other defined office subnets use the tunnel. If the organization requires all browsing to be inspected or logged through the office firewall, full tunnel may be required instead.
Design checklist
Before changing VPN routing, confirm:
- Which subnets remote users must access
- Whether DNS queries should use office DNS or local DNS
- Whether all user internet traffic must be inspected by the office security stack
- Whether users need access to printers, file shares, ERP, CCTV, or admin systems
- Whether MFA, device posture, or user-group restrictions are required
- How logs will be reviewed after deployment
Step-by-step validation approach
1. Document the current VPN behaviour
Connect a test client and record its IP address, default route, DNS servers, and reachable office systems. Do this before changing anything.
2. Decide the intended routing model
Choose full tunnel or split tunnel based on policy, not convenience. Security and compliance requirements should come before bandwidth optimization.
3. Apply the VPN routing change in a test window
Use a test user first. Avoid changing all remote users at once unless there is a rollback plan and a support window.
4. Test internal access
Confirm the remote user can reach only the intended office subnets and applications. If access is broader than expected, review firewall policy and VPN group rules.
5. Test normal internet behaviour
Check the public IP address seen by the remote client. In full tunnel, it should normally appear as the office internet connection. In split tunnel, it should normally appear as the user's local internet connection.
6. Review logs and user experience
Check VPN connection logs, firewall logs, DNS behaviour, and user-reported performance. Record the final design and the reason it was chosen.
Expected result
For split tunnel, remote users should reach approved office resources while normal internet traffic continues outside the tunnel. For full tunnel, all traffic should route through the VPN according to the configured policy.
Troubleshooting
- If internal systems are unreachable, confirm route statements, firewall rules, DNS, and the client configuration.
- If all traffic unexpectedly goes through the office, check whether a default route is being pushed to the VPN client.
- If DNS names fail but IP addresses work, check DNS server assignment and search domains.
- If performance is poor, compare full tunnel and split tunnel bandwidth paths and inspect gateway load.
Security considerations
Split tunneling can reduce office gateway load, but it may also reduce centralized inspection. Full tunneling can improve inspection coverage, but it may create latency and bandwidth pressure.
For vendor or administrator access, avoid broad VPN access where possible. Use user groups, MFA, least privilege firewall rules, logging, and periodic access reviews.
Rollback notes
Keep the previous VPN configuration and a known-good client profile. If users lose access, revert the routing change or temporarily disable the new VPN profile while the route and DNS behaviour are reviewed.