Using TunnelNet With a Corporate VPN
TunnelNet and a corporate VPN or zero-trust client can coexist on the same machine, with limits. Egress works alongside most clients on desktop. Inbound does not. Phones allow one VPN at a time. And we will not help you circumvent a control on hardware you do not own.
The rule, up front
We do not help defeat a control on hardware you do not own. If your employer deploys a zero-trust agent, a VPN, or a split-tunnel policy on a company laptop, that is their machine and their decision. Nothing in this guide is advice on circumventing it, and our support will not help you try. Everything below applies to your own devices.
Desktop: Linux, Windows, macOS
Egress alongside a zero-trust client
TunnelNet Full and TunnelNet Mobile route your outbound traffic through your dedicated address. On desktop, this is a WireGuard tunnel. Most corporate VPN clients and zero-trust agents (Zscaler, Palo Alto GlobalProtect, Cisco AnyConnect, Netskope) also install a tunnel or a virtual interface.
The two can coexist when the routing is split correctly. TunnelNet claims your dedicated address as the source for outbound traffic. The corporate client claims a different set of destinations (typically your employer's internal networks and sometimes all traffic). As long as the corporate client does not force all traffic through its own tunnel, both tunnels work side by side.
If the corporate client runs in full-tunnel mode (all traffic routed through the employer's gateway), it will override TunnelNet's outbound routing. Your traffic will leave through the corporate tunnel, not through your TunnelNet address. There is no workaround for this on a machine where the corporate client has administrative control of the routing table.
Inbound does not work under a corporate VPN
TunnelNet IP routes inbound traffic to your machine. This requires that the WireGuard tunnel between your machine and our hubs is reachable and that packets returning from your machine take the correct path back through the tunnel rather than through the corporate VPN.
A corporate VPN that captures the routing table will break this. Inbound packets arrive via TunnelNet, but replies leave via the corporate tunnel and never reach the sender. The connection appears to hang or time out from the outside.
If you need inbound connectivity, disconnect the corporate VPN first or use a separate machine. There is no configuration on our side that fixes asymmetric routing caused by another tunnel claiming the default route.
Mobile: phones and tablets
iOS and Android allow exactly one VPN connection at a time. This is an OS-level constraint, not ours. If your employer's MDM profile installs a VPN, activating TunnelNet Mobile will disconnect it, and vice versa.
You switch between them. When you need your corporate VPN, use it. When you want your outbound traffic to leave as your own address, switch to TunnelNet Mobile. Both are configured in the WireGuard app and switching takes a tap.
If your employer's MDM enforces an always-on VPN policy, TunnelNet Mobile cannot run at the same time. This is by design on the phone OS's part, and we cannot override it.
What works and what does not
Works: egress on a personal desktop alongside a split-tunnel corporate client
Your outbound traffic leaves as your TunnelNet address. Corporate traffic goes through the corporate tunnel. Both tunnels are up. This is the common case for people who work from home on their own machine and connect to a corporate VPN for internal resources.
Does not work: inbound while a full-tunnel corporate VPN is active
Asymmetric routing breaks it. Inbound packets arrive via TunnelNet but replies leave via the corporate tunnel. Use a separate machine or disconnect the corporate VPN.
Does not work: two VPNs simultaneously on a phone
iOS and Android enforce one VPN at a time. Switch between them as needed.
Does not work: bypassing an MDM-enforced always-on VPN
If the device management profile enforces the VPN, the OS will not let you replace it. That is the employer's machine, not yours.
The honest limits
We do not control your routing table when another agent also claims it, and we will not race one for control. If your corporate client and TunnelNet disagree about where outbound packets go, the one with higher routing priority wins, and that is usually the corporate client because it was designed to win that fight.
The practical answer for most people: use TunnelNet on your own hardware. A personal laptop, a home server, your own phone on your own account. That is the machine where the routing table is yours to decide, and where both tunnels can coexist cleanly.