Travel Router With a Corporate VPN (Cisco AnyConnect, GlobalProtect, Zscaler): Does It Actually Work?

If your company issues you a laptop with Cisco AnyConnect, GlobalProtect, or Zscaler Client Connector on it, and you also want to run your own travel router underneath that for a consistent, home-style connection, the honest first question is whether that's even going to work, or whether the corporate VPN client is going to notice, block it, or just break.

The short answer: it almost always works, because these two things operate at completely different layers, and they're not actually looking at each other. But there's one real, well-documented technical snag worth understanding before you set this up, and it has nothing to do with detection.

To be clear about what this is and isn't: this is about keeping a stable, ordinary-looking connection for a company-issued device you're already authorized to use remotely, the same ground covered in our piece on what your employer can and can't actually detect. It's not about hiding anything from software already running on that device, and it doesn't change what your corporate VPN client can see once its own tunnel is up.

Why this isn't really a "double VPN" fight

A travel router sits at the network layer. It's the thing your laptop's WiFi connects to, and everything on that network, corporate VPN client included, just sees it as "the internet." Your corporate VPN client sits at the application layer, on top of whatever network it finds. This is exactly the same relationship as using AnyConnect over your home WiFi, over hotel WiFi, or over a coffee shop's network. The travel router is just one more ordinary network in that same category, it's not inserting itself into the corporate tunnel or intercepting anything inside it once that tunnel is established.

Here's what each of the three major corporate VPN clients actually checks before and during a connection, based on their own documentation.

Cisco AnyConnect's Trusted Network Detection. This feature decides whether AnyConnect should auto-connect or auto-disconnect based on whether the device looks like it's already on the corporate network. Per Cisco's own admin documentation, it checks three things: the DNS suffix assigned to the active network interface, the DNS servers assigned to that interface, and whether a specific trusted internal host is reachable with the right certificate. Nowhere in that logic is your public IP address, your ISP, or where your traffic physically originates. A travel router handing out its own DNS and its own local network simply reads as "not the corporate network," the same as any other network you'd connect from remotely, so AnyConnect connects normally.

Palo Alto GlobalProtect's Host Information Profile (HIP) check. This one gets confused with network-level inspection a lot, but per Palo Alto's own documentation, HIP is entirely about the state of the endpoint itself, not the network it's connected through. It checks things like whether OS patches and antivirus definitions are current, whether disk encryption is enabled, and whether the device is jailbroken or rooted. It has nothing to do with your public IP, your ISP, or what's between your laptop and the internet. A travel router doesn't touch any of the signals HIP actually evaluates.

Zscaler Client Connector. Zscaler works a little differently since it's built around always routing traffic through Zscaler's cloud rather than a traditional site-to-site tunnel, but its trusted-network logic follows the same general pattern as the other two: it's evaluating local network adapter characteristics to decide whether you're already inside the corporate network, not inspecting your ISP or the reputation of your underlying connection. Zscaler documents this under its own "trusted network" configuration guidance for admins. Same conclusion as above: a travel router is just another external network to it, same category as home WiFi.

The real issue: double encapsulation and MTU

This is the part that actually trips people up, and it's not about detection at all, it's about packet size.

When your travel router is already running its own VPN tunnel (WireGuard or OpenVPN, wrapping every packet in its own encryption headers), and then your corporate VPN client establishes a second tunnel on top of that, you've got two layers of encapsulation. Each layer adds overhead, and if the resulting packets end up larger than what the path in between can carry, they get fragmented or dropped instead of delivered cleanly.

In practice this doesn't look like a connection failure, it looks like AnyConnect or GlobalProtect connecting just fine but then specific things breaking: mapped network drives that won't load, softphone apps like Cisco Jabber failing to register, video calls that stutter or drop, file transfers that hang partway through. This exact scenario, a router-level VPN plus AnyConnect on top of it, shows up in Cisco's own community forums and in GL.iNet's own support forum, both describing the identical fix: the MTU needs to come down.

The cleanest place to fix this is on the travel router itself, not the company laptop. Most travel routers let you set a custom MTU on the WireGuard or OpenVPN client interface. Lowering it, commonly somewhere in the 1280 to 1350 range depending on your setup, gives the corporate tunnel enough headroom inside the residential tunnel that packets stop getting fragmented. This keeps the fix entirely on hardware you control and never touches settings on a company-managed device, which is worth doing anyway even if you could adjust it there too.

If mapped drives or a softphone app are acting up after adding a travel router into the mix, this is almost always the actual cause, not anything to do with detection or policy.

What this is actually useful for

Keeping one consistent, stable network for a company-issued device you already use remotely, the same connection every time instead of a different unfamiliar network every hotel or Airbnb, which is the thing that tends to trip security holds and MFA prompts in the first place. Nothing here changes what your employer's own software on that device can see, and nothing here is about accessing anything you're not already authorized to access. If you haven't read it yet, our piece on what your employer can and can't detect covers that distinction in more depth.

Quick answers

Will Cisco AnyConnect, GlobalProtect, or Zscaler detect or block a travel router underneath them? No, not based on what any of them actually check. AnyConnect looks at DNS suffix, DNS servers, and a trusted internal host. GlobalProtect's HIP check looks at endpoint software state, patches, antivirus, disk encryption. Zscaler evaluates local network adapter characteristics the same general way. None of them inspect your ISP, your public IP, or where your underlying connection originates.

Why did my mapped drives or Jabber stop working after adding a travel router? Almost always MTU and packet fragmentation from running two VPN tunnels at once, not a detection or policy issue. Lowering the MTU on the travel router's VPN client interface, commonly to somewhere around 1280 to 1350, is the standard fix.

Do I need to change any settings on my company laptop to fix this? No. The fix belongs on the travel router's own VPN client settings, which keeps you from needing to touch anything on a device your company manages.

Does this hide anything from software my company already has installed on my laptop? No. Anything already running on a company-managed device, endpoint monitoring, MDM, browser extensions, sees exactly what it saw before. A travel router only affects the network underneath, not software already on the device itself.

The short version

A travel router and a corporate VPN client aren't actually competing for the same job, one operates at the network layer, the other at the application layer, and none of the big three, AnyConnect, GlobalProtect, or Zscaler, check anything about your underlying ISP or IP address before connecting. The one real issue worth planning for is packet fragmentation from running two VPN tunnels at once, which shows up as broken file shares or dropped calls rather than a connection failure, and the fix lives entirely on the travel router's own settings.

Want a stable, consistent connection for your remote work setup that plays well with whatever your company already runs? Start your free trial and get your travel router configured before your next trip.