The Truth Behind My Company VPN Lag
The company VPN was only supposed to affect private network ranges in the 192.168 block. Yet every time I turned it on, my local internet connection would slow to a crawl as well. This problem bothered me for two whole years, and I finally solved it recently with the help of AI.
The conclusion first: after connecting to the company VPN, the route range pushed by the VPN overlapped with the private network range configured on my home router, causing DNS resolution timeouts.
How It Started
Since I started working from home, I have regularly used the company VPN to access the internal network. But whenever I turned it on, my internet connection would become painfully slow, even though the company's remote desktop still worked smoothly.
The company VPN uses split tunneling, so ordinary internet traffic should theoretically continue through my home connection. There should not have been any slowdown.
The specific symptom was this: whenever I opened a web page or started another network service, it would spin for nearly 10 seconds at the beginning. Once connected, however, it would return to normal speed. Ordinary web browsing, research, and video playback were mostly fine. Services that needed frequent refreshes, however, would easily time out or even decide that the connection had dropped. It was extremely annoying in daily use.
Asking AI to Investigate
After I gave Codex the exact symptoms, it found a clue in the LAN configuration:
- Original home configuration:
- LAN: 192.168.1.0/24
- Home router and DNS: 192.168.1.1
- Company VPN configuration:
- Company route pushed by FortiClient: 192.168.0.0/17
- Actual covered range: 192.168.0.0 to 192.168.127.255
That meant my home 192.168.1.x addresses fell inside the range announced by the company VPN. The Forti virtual adapter was also configured to use my home router as its DNS server. The overlapping ranges were very likely interacting with FortiClient's DNS or packet-filtering mechanisms, causing UDP DNS timeouts and retries. Once a retry finally succeeded, the DNS result entered the cache and subsequent connections returned to normal. That was why the beginning of every connection was especially slow.
The Solution
Logging In to the Chunghwa Telecom Router
My router is a Chunghwa Telecom gateway, model Zyxel PMG4506-T20B. I needed to log in with its administrator account. The default address is 192.168.1.1 or 192.168.0.1.
The default user/user account did not have permission to change the LAN settings. After some googling, I learned that the password varies by gateway model. For my model, the default administrator credentials were cht/t20b37b0.
If your device is still using its default credentials, remember to change them too. Kissy face ^.<.
Changing the LAN Configuration
The private route pushed by the company was 192.168.0.0/17, covering 192.168.0.0 to 192.168.127.255. I therefore decided to leave that entire range to the company and move my home IP configuration further back:
- LAN IP: 192.168.200.1
- Subnet Mask: 255.255.255.0
- DHCP start: 192.168.200.101
- DHCP end: 192.168.200.200
After the change, my new home network became 192.168.200.0/24. The 192.168.200.x addresses no longer fell within the company VPN's /17 range, resolving the conflict.
Once the configuration was updated, the 10-second delay at the beginning of every connection disappeared. My local internet returned to normal, and the case was closed.
English translation provided by Codex.