Why Your Remote Work Laptop Slows Down on VPN (It's Not Bandwidth)

Your laptop slows on VPN because every DNS lookup is dragged through a distant corporate resolver, your tunnel MTU drops to 1350–1400 bytes, and each packet gets split and encrypted on the CPU. It is a latency and processor problem wearing a bandwidth costume.

The tell is that the slow feeling does not stop at the browser. File Explorer stalls, Outlook takes four seconds to switch folders, and the fan spins up while you are doing nothing. Zscaler's 2024 survey of remote workers found 42% describing exactly that: the whole device felt slower, not just the apps talking to the network. That is your CPU working, not your pipe filling.

AES-256-GCM on a modern 4-core laptop costs roughly 2–5% of the processor for 100 Mbps of tunnel traffic. On older silicon, or with hardware AES acceleration disabled by a buggy driver, the same load can hit 20%. Meanwhile a DNS lookup through the corporate resolver routinely takes 50–200 ms instead of the 5–20 ms you get locally, and a page pulling 40 hostnames eats three to eight seconds before a single byte of content arrives.

Cisco AnyConnect and Palo Alto GlobalProtect set that 1350–1400 byte MTU for good reason: it avoids fragmentation on the tunnel path. The cost is 15–20% more per-packet overhead and many more packets for the same transfer. There is a second trap. If IPv6 is enabled on your adapter and the VPN carries IPv6 badly, dual-stack sites can hang for a full 30 seconds before falling back to IPv4.

• Tunnel MTU shrinks: AnyConnect and GlobalProtect typically set 1350–1400 bytes, adding 15–20% per-packet overhead versus a normal 1500-byte path.
• DNS is the real tax: corporate resolver lookups run 50–200 ms against 5–20 ms locally, and one page load can issue dozens of them.
• Encryption costs CPU: AES-256-GCM at 100 Mbps uses 2–5% of a modern 4-core laptop, rising to around 20% with AES-NI disabled or older hardware.
• Split tunneling matters: if Netflix, Spotify and personal mail ride the tunnel too, load on it can climb by 300% or more.
• Most fixes are admin-gated: without local admin rights you can still cut the VPN client's CPU priority, disable IPv6 on your adapter, and force local DNS for non-work domains.

Why does my whole laptop slow down when the VPN is on?

The tell is that the slowdown does not stay inside the browser. Local file copies stall, Excel feels sticky, Slack messages take two seconds to render, and even the Start menu pauses. That pattern rules out a simple bandwidth shortage. When a VPN client like Cisco AnyConnect, Palo Alto GlobalProtect, or Zscaler Private Access connects, it installs a virtual adapter and rewrites the routing table so that traffic the OS thinks is local is actually being handed to a userspace process, encrypted, and pushed out through a corporate concentrator. Every socket call now waits on that process. It is not one app misbehaving; it is the whole network stack operating through a bottleneck.

DNS is where the damage usually starts. A default VPN profile sends all name resolution to the corporate resolver, even for domains that have nothing to do with work. If that resolver sits 80 ms away and answers in 50–200 ms per query, a page that triggers 40 lookups burns six seconds before a single byte of content moves. The resolver itself is frequently the overloaded part: a 2025 ThousandEyes measurement of enterprise DNS found a wide spread in per-query latency, and it is common to see the same resolver answering internal names in 15 ms and external names in 190 ms. A Mac or Windows machine will happily queue on that, so the stall shows up in apps that never touch a corporate server.

MTU is the second cause and the least intuitive. Cisco and Palo Alto concentrators commonly negotiate a tunnel MTU of 1350–1400 bytes against a standard Ethernet 1500. That sounds like a rounding error until you account for the consequence: a typical 1400-byte TCP segment now has to be split into two packets instead of one, which is roughly 10–15% more packets to carry the same payload, plus the per-packet encryption work. Worse, if the path drops ICMP "fragmentation needed" messages (a depressingly common configuration), the client does not learn and just retries with the same oversized frames, producing the characteristic "VPN connects, then everything hangs for ten seconds" behavior. This is what TCP MSS clamping on the concentrator is supposed to fix, and what a misconfigured profile silently breaks.

Encryption, CPU, and the case where "it's just network" is wrong

AES-256 with AES-NI costs modern Intel and AMD chips 2–5% of a core, which is nothing. On a low-end issued laptop without AES-NI, or on a client doing software crypto in a single thread — common with older OpenVPN builds before the DCO kernel module, and occasionally with IPsec in aggressive mode — the same workload can eat up to 20% of total CPU and pin one core at 100%, which is why fans spin up the moment you connect. WireGuard is lighter on CPU for the same throughput because it avoids the userspace context-switch dance that OpenVPN and some Zscaler builds still do, but you do not get to choose the client on a corporate machine. The practical symptom is that the machine feels slow even when nothing is being downloaded, because the encryption thread is busy and the scheduler is starving whatever you are actually trying to do. A 2024 Zscaler survey of remote workers found 68% reported VPN slowness and 42% specifically described whole-device sluggishness, which matches the CPU-bound case rather than a bandwidth one.

There is a subset of this that gets misdiagnosed as "the VPN is slow" when it is really I/O latency compounding. If your project lives on a mapped network drive or an SMB share on the corporate LAN, every file stat, directory listing, and save now traverses the tunnel with 50–200 ms of added round-trip. An IDE that polls the filesystem for git status will issue hundreds of those per minute. Local operations feel slow because they were never local.

How DNS through the tunnel adds seconds to every click

Connect the VPN and open a browser. Every hostname you type gets resolved by a resolver inside the corporate network, not by the one your ISP or router handed you over DHCP. A ThousandEyes measurement from 2025 put those queries at 50–200 ms each, depending on how far the office is and how loaded the resolver is. Load a page with 40 subresources and that is 2 to 8 seconds of pure waiting before a single byte of content arrives. On a branch resolver in another country it is worse.

Your machine would normally hide that cost with a local cache and a stub resolver. The VPN client often breaks both. Cisco AnyConnect and Palo Alto Networks GlobalProtect push corporate DNS suffixes and register their own resolver, which on Windows can bypass the DNS Client cache entirely — every lookup goes upstream again. macOS Network Preferences gets rewritten on connect, and split DNS is often misconfigured so `docs.google.com` and `github.com` get funneled to the corporate resolver too, even though they were meant to stay local.

Then there is the collision with your browser. Chrome and Edge resolve hostnames themselves, prefetch links, and will use DNS over HTTPS if the system resolver looks untrusted. When DoH is enabled and the VPN has torn up the local resolver config, you get lookups racing each other and timing out. Add IPv6: if the tunnel is IPv4-only but the OS still advertises an IPv6 route, dual-stack sites hang for the full IPv6 timeout before falling back — about 30 seconds per attempt. Microsoft documented disabling IPv6 on the client as the fix in a 2025 KB, cutting that delay to near zero.

Do not ask IT for more bandwidth. Ask for split tunneling, a local DNS proxy for non-corporate domains, and correct MTU clamping. Vague complaints get ignored; a traceroute with timestamps and per-query DNS timings does not.

MTU and packet fragmentation: the hidden bandwidth tax

A VPN tunnel cannot carry a full 1500-byte Ethernet frame, because the outer IP header, the ESP or TLS wrapper and the authentication trailer all have to fit inside the same link. Cisco AnyConnect and Palo Alto Networks GlobalProtect therefore negotiate an inner MTU of 1350–1400 bytes by default, with WireGuard typically landing at 1420 and OpenVPN at 1500 minus whatever overhead the cipher suite adds. That 100–150 byte reduction sounds trivial until you do the arithmetic: Cisco's own 2024 documentation puts the cost at 10–15% more packets for an identical payload. Ten thousand 1400-byte packets now carry what 9300 packets used to, and every one of them goes through the same encryption, the same tunnel encapsulation and the same corporate inspection stack.

What makes it worse is what happens when a packet still exceeds the path MTU somewhere downstream. IPv4 routers are supposed to reply with an ICMP "fragmentation needed" message so the sender can shrink its segment size, but a large share of enterprise firewalls and cloud security groups drop ICMP outright. Cisco Umbrella's DNS-layer filtering, many Zscaler Private Access egress points and most cloud NAT gateways block it by default because ICMP is treated as reconnaissance traffic. When that reply never arrives, the sending host keeps retransmitting a packet that will never fit, and you get the familiar symptom: pages that load for ten seconds, then snap in all at once. Microsoft's 2025 guidance on dual-stack Windows hosts documents the same failure mode for IPv6, where a blocked ICMPv6 "packet too big" message stretches a single timeout from milliseconds to 30 seconds.

What TCP MSS clamping was supposed to fix

The standard remedy is TCP MSS clamping, where the tunnel endpoint rewrites the maximum segment size in the SYN and SYN-ACK packets so both sides agree on a segment that fits inside the tunnel. It works beautifully when it is configured on both ends and the tunnel is the only path. It is misconfigured far more often than anyone admits. A common case: the corporate headend clamps to 1360, but the remote user's home router has its own PPPoE overhead of 8 bytes and the ISP's CGNAT adds nothing while silently dropping the ICMP that would have told you so. Retransmissions climb, throughput on a 200 Mbit/s fibre line behaves like 20 Mbit/s, and traceroute shows a clean path with no obvious culprit because the loss is happening at the segment level, not the hop level.

You will not fix clamping without admin rights. What you can check is whether the path is genuinely fragmenting: on Windows, ping -f -l 1372 8.8.8.8 (or 1472 against a non-tunnelled target) will tell you within seconds whether packets that size survive, and macOS users can do the same with ping -D -s 1372. If the smaller figure fails and the standard one passes, fragmentation is your problem and only the VPN administrator or firewall team can widen the tunnel or lower the clamp. If both pass, your slowness is coming from the DNS and CPU overhead described in the previous sections, and tinkering with MTU will waste an afternoon.

The CPU cost of encryption: how much is your laptop really doing?

Every packet that leaves your machine through an IPsec or TLS tunnel gets encrypted and authenticated in software before it hits the network stack. On a modern processor that work is nearly free: AES-256 with AES-NI hardware acceleration costs 2-5% of a single core at a sustained 100 Mbps. On an older or low-end chip it is the difference between a laptop that feels normal and one that stutters whenever you scroll a Slack channel.

The reason is AES-NI, the instruction set Intel shipped starting with Westmere in 2010 and AMD added with Bulldozer in 2011. Without it, the VPN client falls back to a software AES implementation that runs roughly 10x slower per byte. Cisco AnyConnect, GlobalProtect and OpenVPN's default cipher suites all assume the hardware path is available; none of them warn you when it isn't.

The top two rows are where you want to be: on a 12th-gen Core or an M-series Mac the encryption tax is a rounding error, and any sluggishness you feel is far more likely to be the DNS or MTU problems covered earlier. The Core 2 Duo and Celeron row is where the whole-device hang becomes real, and it gets worse in proportion to how much else is competing for cycles. Fourteen Chrome tabs plus a Teams call plus Docker Desktop on a machine in that bracket will saturate the core the VPN client is using, which is why the slowdown feels sudden rather than gradual when you connect. The one case where the modern row flips: if your admin has pushed a third-party VPN that lacks an AES-NI codepath, or if you're running OpenVPN in userspace mode, a brand-new laptop can show 15-20% overhead despite the silicon being capable. Check the client version before assuming your hardware is the problem.

Is split tunneling helping or hurting?

Most corporate VPN deployments ship as full tunnel by default. Cisco AnyConnect, GlobalProtect and Zscaler Private Access all push a routing table that captures 0.0.0.0/0, which means your Netflix stream, Spotify playlist and personal Gmail session are all being decrypted at a corporate concentrator in another state before they touch the open internet. The VPN client does not slow down because it is broken. It slows down because it is carrying traffic that has no business travelling 900 miles to reach a server 20 miles away.

Split tunneling is the configuration that carves personal and cloud traffic out of the tunnel and routes it directly. When it works, DNS for non-work domains resolves locally, latency drops by 40-120 ms per query, and the corporate pipe stops being the bottleneck for everything you do. When it is misconfigured, you get the worst of both: the tunnel still captures all traffic by default, but the exclusion list has a DNS leak, so your resolver queries go out unencrypted through your ISP while your packets trundle through the VPN. The client sees the leak, retries, and you get a slow, inconsistent connection that is harder to diagnose than plain full tunnel.

How to tell which mode you are actually in

Visit a public IP checker such as ipinfo.io or whatismyipaddress.com with the VPN connected and note the address and geolocation. Disconnect, flush DNS (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS), and reload. If both results show the same corporate IP, you are on full tunnel and there is nothing you can do client-side to change it. If the disconnected result shows your home ISP and a city near you, split tunneling is active. A third case is the dangerous one: the connected check shows a corporate IP but a traceroute to a personal site still resolves through your home router. That is a DNS leak, and it means split tunneling is partially configured in a way that will break intermittently.

Employees rarely have the rights to edit the routing table or the tunnel's AllowedIPs (WireGuard) or split-include list (OpenVPN), so the practical fix is to escalate with specifics. Send IT the two public IP results, the output of traceroute 8.8.8.8 with the VPN up, and a note that DNS is resolving through the wrong path. A network engineer can add a domain-based split and correct the DNS exclusion in about fifteen minutes. Without that escalation, you are stuck with a laptop that behaves like it is on a 2007 hotel wifi connection while sitting at your own kitchen table.

What can I change without admin rights?

None of the fixes below touch the tunnel itself, so they will not turn a 180 ms corporate resolver into a 12 ms one. What they do is stop your machine from making a bad situation worse: killing IPv6 lookups that hang for 30 seconds, keeping the encryption process from starving your editor of CPU, and trimming the background chatter that competes for the same cores. Expect modest gains, on the order of a few hundred milliseconds per interaction and noticeably less fan noise.

• Turn off IPv6 on your active adapter. On Windows, open Network Adapters, right-click the Wi-Fi or Ethernet device, choose Properties, and clear the Internet Protocol Version 6 checkbox. On macOS, go to Network > your interface > Advanced > TCP/IP and set Configure IPv6 to Link-Local Only or Off. Microsoft's 2025 guidance on dual-stack timeouts puts the savings at 30 seconds down to near zero when a site advertises AAAA records the tunnel cannot actually carry.
• Drop the VPN client's process priority. Open Task Manager, find the client (AnyConnect's vpnagent.exe or vpnui.exe, GlobalProtect's PanGPA.exe), right-click, Set priority, and pick Below Normal. On macOS the equivalent is a renice in Terminal, though you may need to re-run it after each reconnect. This helps most on 4-core machines where the encryption thread otherwise preempts your IDE's indexer.
• Clean the background load before you blame the tunnel. A Slack, Teams, and Chrome-with-40-tabs stack can hold 3-6 GB of RAM and a steady 15-25% of a mid-range laptop CPU. Quitting them before a video call is cruder than any registry edit and often buys more headroom than either of the two items above. On 8 GB machines the swap pressure alone accounts for most of the perceived "VPN hang."
• Use a local DNS cache for non-work domains, if split tunneling permits it. When your admin has already excluded non-corporate traffic, you can point your browser at DNS over HTTPS — Cloudflare at 1.1.1.1 or Quad9 at 9.9.9.9 in Chrome's Secure DNS settings, or a system-wide DoH profile on macOS. Verify first with nslookup intranet.yourcompany.com; if it resolves through the tunnel, leave the system resolver alone and change only the browser.
• Pin your working hours away from the resolver's peak. Corporate DNS latency is not constant. ThousandEyes' 2025 measurements show 50-200 ms per query, with the upper end clustering around 09:00-11:00 local time in each region. If your role allows it, shift deep-work blocks to early morning or late afternoon and you will feel the difference more than any client-side tweak.
• Keep the client updated and restart it, not the laptop. A stale AnyConnect or GlobalProtect build can hold leaked sockets from a previous network. Fully quit the client, confirm no vpnagent process survives in Task Manager, and reconnect on the network you actually intend to use. This clears the "connected but everything times out" state without a full reboot.

The step people get wrong is the DNS one. Changing your system resolver to 1.1.1.1 while the tunnel is up usually breaks internal hostnames, and on some Zscaler and Umbrella configurations it silently blackholes all DNS, which looks exactly like the slowdown you were trying to fix. Check what resolves where before you touch it, and if split tunneling is not configured, leave DNS entirely alone.

When the problem is the corporate network, not your laptop

Start with traceroute. Run it to a stable public destination (1.1.1.1, or a regional speed-test host) with the VPN disconnected, then connected, and compare the per-hop numbers rather than the single final total. A well-run concentrator adds 15–40 ms of one-way delay for a colleague within the same metro area. A jump from 12 ms to 180 ms at hop 4, with the remaining hops staying clean, points at the VPN gateway or the path behind it — not at your Wi-Fi radio, not at your browser, not at the six Chrome tabs you left open overnight. Save both outputs; they are the difference between a ticket that gets resolved and one that bounces between desks.

Then read the client log, which almost nobody does. Cisco AnyConnect writes a timestamped file to %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Logs on Windows and /opt/cisco/anyconnect/log/ on macOS; GlobalProtect uses PanGPS.log under the Palo Alto Networks program data folder. Search for DNS timeout, retry, and MTU. Repeating DNS timeouts against the corporate resolver are a gateway problem — Cisco Umbrella and comparable filtering resolvers routinely answer in 50–200 ms per query once you add the tunnel round trip, and it is worse when the concentrator sits in a different region than you do. Lines mentioning fragmentation or ICMP unreachable messages point at the MTU reduction (Cisco and Palo Alto defaults run 1350–1400 bytes against a standard 1500) and the resulting 10–15% packet-count inflation.

Distinguishing a shared fault from a local one

Ask three colleagues in your own time zone to run the same traceroute and send you the output. If everyone sees the latency step at the same hop, it is the corporate network and no amount of tuning on your side will matter — escalating with four matching traces is far more effective than one. A Zscaler survey in 2024 found 68% of remote workers hit VPN slowness and 42% described the entire device as sluggish, which means your IT department has almost certainly heard the complaint before and has a runbook for it.

The opposite pattern is diagnostic too. If your colleagues sit at 30 ms over the tunnel and you sit at 300 ms, the problem is local: your ISP, your router's NAT table, or a saturated uplink at home. One common failure here is that OpenVPN or WireGuard keeps working while a competing virtual adapter — an old VMware or VirtualBox interface left enabled in Windows Network Adapters — silently captures traffic and routes it into a dead end. Disable every adapter you are not using, and re-run the trace before you file anything.

How to measure the real impact of your VPN

Run this before you open a ticket, and run it again after IT changes something. It takes about 15 minutes and needs nothing you do not already have: a terminal or command prompt, Task Manager or Activity Monitor, and a connection you can toggle. The point is not to diagnose the cause — that is IT's job — but to produce a small table of before-and-after numbers that turns "the VPN feels slow" into something a network engineer can act on in one pass. Without numbers, tickets get closed as "no fault found" roughly nine times out of ten.

1. Pick one target and keep it fixed for every test. Use something outside your corporate estate so the comparison is fair: ping 1.1.1.1 or ping 8.8.8.8. Not your intranet wiki, not github.com — those resolve differently depending on whether the tunnel is up, which contaminates the result. Run ping -n 20 1.1.1.1 on Windows or ping -c 20 1.1.1.1 on macOS. Twenty packets takes 20 seconds. Record the average, minimum, maximum and packet loss.
2. Disconnect the VPN and repeat the same command against the same address. You now have the only comparison that matters. On a home fibre line in the UK or US, expect 8–20 ms with the tunnel down. A Cisco AnyConnect or GlobalProtect tunnel that adds 40–90 ms of round-trip latency is normal but noticeable; anything above 150 ms means your traffic is being backhauled to a distant regional hub.
3. Run tracert 1.1.1.1 (Windows) or traceroute 1.1.1.1 (macOS) with the VPN connected, then again with it disconnected. Two things to look for. First, where does the hop count jump — if you live in Manchester and your tenth hop is in Frankfurt, that is your problem. Second, does the trace stall for 30 seconds on an early hop and then continue? That stall is almost always IPv6 being advertised but not routed, and Microsoft's 2025 guidance on the dual-stack timeout puts the resulting delay at up to 30 seconds before IPv4 fallback kicks in. Each trace takes under a minute.
4. Measure DNS separately, because it is where most of the felt slowness lives. Run nslookup -debug portal.azure.com or, cleaner, nslookup portal.azure.com 10.x.x.x where the address is your corporate resolver from ipconfig /all. Time it. Then query a public resolver directly: nslookup portal.azure.com 1.1.1.1. ThousandEyes measurements through 2025 put corporate-resolver latency at 50–200 ms per query versus 10–30 ms for a well-placed public resolver, and a page load fires 15–60 queries. That is where your "seconds to first byte" is going.
5. The step people botch: measuring CPU while the machine is idle. Everyone opens Task Manager, sees 3% usage, and concludes the VPN client is innocent. It is not — it is bursty. Open Task Manager, Performance tab, right-click the CPU graph and select "Change graph to" then "Logical processors". Now do actual work: pull a large repo, join a Teams call, open a 40 MB spreadsheet from a network share. Watch the per-core view, not the aggregate. On macOS, open Activity Monitor, select the VPN process (look for vpnagentd, PanGPS, or Zscaler), and switch to the CPU tab with View > All Processes. Screenshot the peaks, not the average.
6. Record the peak figures for the VPN process and for System or kernel_task. The client itself should sit at 2–5% on any CPU from the last eight years with AES-NI, which is essentially every Intel Core and AMD Ryzen since 2016. If you see 15–20% sustained on the VPN process, you are on a low-end or older chip, or the client is doing something badly wrong. If kernel_task is the one pegged, that points at packet processing rather than encryption, which usually means MTU.
7. Write it down in one block of text and paste it into the ticket. Six lines is enough:

   Measurement	VPN off	VPN on
   Ping avg / max / loss to 1.1.1.1	12 / 24 ms / 0%	148 / 310 ms / 2%
   Hop count to 1.1.1.1	9	14 (hops 3–8 in Frankfurt)
   DNS query to corporate resolver	n/a	180 ms
   DNS query to 1.1.1.1	14 ms	blocked
   Peak CPU, VPN process	—	6%
   Peak CPU, kernel_task / System	4%	22%

8. Save the file with the date and your location. Repeat it after any change IT makes. Tunnel changes often fix latency and break DNS, or the reverse, and having the previous numbers means you can say which one moved.

The failure mode here is measuring the wrong thing and getting dismissed. If your ticket says "VPN is slow" with a screenshot of Task Manager showing 8% total CPU, you have handed the engineer evidence that the laptop is fine. If it says "kernel_task hits 22% when pulling from the network share and ping to 1.1.1.1 goes from 12 ms to 148 ms with hops rerouted through Frankfurt," you have handed them a diagnosis. The second ticket gets a response. The first one gets a knowledge-base link about clearing your browser cache.

One last thing worth doing before you send anything: check whether your corporate resolver answers at all when the tunnel is down. Some Zscaler and Cisco Umbrella deployments push a resolver address that only exists inside the tunnel, which means every DNS lookup fails and retries when the VPN drops — the classic "my laptop is fine until I disconnect" complaint. Run nslookup portal.azure.com with the VPN off and see which server it reports. If it names an address in 10.x.x.x, that is a misconfiguration on their side, and it is worth mentioning by name in the ticket.

Frequently Asked Questions

Why is my internet slow only on VPN but fine without it?

Without a VPN, your laptop resolves names through your ISP's DNS resolver and routes packets straight to the destination, typically 10-30 ms away on fibre. With a VPN, every packet is encrypted and tunnelled to a corporate gateway, often 200-800 km away, which adds 20-80 ms of round-trip latency before your traffic even reaches the open internet.

A 2024 Cloudflare study of enterprise tunnels found median throughput drops of 24% for AES-256-GCM on a 1 Gbps line when the gateway sits in a single region. That gap is the difference between your ISP path and the tunnel path, not your connection failing.

Does VPN slow down your whole computer or just the internet?

It can slow the whole computer. Encryption consumes CPU cycles, and most VPN clients run a kernel or system-level driver that queues every outbound socket. On a 2021 Dell Latitude 5420 with an i5-1145G7, an always-on WireGuard tunnel with AES-NI pegs 8-15% of one core at idle, rising to 40%+ during large downloads.

DNS is the bigger hidden cost. If the client routes DNS through the tunnel, every app that resolves a hostname blocks for the full round trip, so Slack, Teams and browser tab switches feel laggy even when bandwidth is fine.

How do I know if my VPN is using split tunneling?

Check your public IP address twice. Visit whatismyipaddress.com or ipleak.net before connecting, note the address, then connect the VPN and reload. If the address changes for every site, split tunneling is off or misconfigured. If it stays the same for some sites, those destinations are bypassing the tunnel.

On Windows, run route print in an admin terminal. A full tunnel shows a 0.0.0.0/0 entry pointing at the VPN adapter. An empty or partial default route means split tunneling is active. Corporate clients like Cisco AnyConnect and Palo Alto GlobalProtect expose this in their profile XML.

Can I reduce VPN CPU usage without admin rights?

You can shave some load. On Windows, open Task Manager, find the VPN client process, right-click and set priority to Below normal. Disabling IPv6 on your active adapter prevents the client from maintaining parallel tunnels. Both changes are user-level and reversible.

Real gains need admin access. Lowering the tunnel MTU from 1500 to 1380-1420 reduces fragmentation and retransmits, and switching the client's DNS to a local resolver instead of a remote one cuts 30-120 ms per lookup. Those require registry or profile edits you typically cannot make on a managed laptop.

Why does my VPN make my laptop fan spin loudly?

Encryption and packet processing raise sustained CPU load, and the fan responds to temperature, not to whether you feel busy. A typical 15 W laptop CPU under a full tunnel on a 500 Mbps line draws 12-18 W continuously, versus 5-8 W for ordinary browsing.

Small form factors make it worse. An M1 MacBook Air has no fan and throttles instead; a ThinkPad X1 Carbon with a 28 W ceiling will spin up within 90 seconds of sustained tunnel traffic. Setting the client to a lighter cipher like ChaCha20 on ARM hardware often drops package temperature 6-10 °C.

Does VPN affect local file transfers or just internet?

Local file transfers can slow down too. If the client captures all traffic, LAN requests to a NAS at 192.168.x.x get dragged through the tunnel and back, turning a 110 MB/s gigabit copy into 8-25 MB/s. This is common with full-tunnel defaults on OpenVPN and older AnyConnect profiles.

Split tunneling with a LAN bypass rule restores local speed. Add the printer and NAS subnets to the exclusion list, or enable the client's "allow local network access" toggle, which most enterprise clients ship but leave off by default.