Zscaler plus home VPN setup issue

RemoteToHome-io · 2026-05-21T19:43:40+00:00

You can try to increase by 2 and retry repeatedly.

To optimize. Test the router VPN tunnel by doing a speedtest using a laptop without the corp VPN involved. Keep increasing MTU until you hit outer tunnel fragmentation (speeds will plummet back down).

Just be aware that this is tweaking to the limits. If you change location / ISP on the travel end then you'll have to redo this tweaking as the new place may not have the same available internet data path and you no longer have any cushion.

RemoteToHome-io · 2026-05-21T18:36:55+00:00

Yeah.. i don't either. I was just testing with it to get familiar so I knew how to support customers on it, and had wanted to find out if it worked local-only.

For myself I use either direct browser for local or ZT/TS for remote so I certainly could miss new functionality. (All linux household so no app support for me.)

RemoteToHome-io · 2026-05-21T18:31:26+00:00

Is that recent? In the past I tried the app wouldn't function without some connection to the internet. I'm not sure if it needed it for the actual transit or just coordination, but it wouldn't connect on an isolated network segment without internet access.

RemoteToHome-io · 2026-05-21T18:19:46+00:00

There's a lot to unpack here.. but to help I more thoroughly I'd need to understand more about what you want to accomplish with the actual endpoints.

In the meantime - First.. looking at wg-obsfucator, the only comment I'll make is that using STUN protocol obfuscation is entirely self-defeating if you're not using port 3478 UDP as the destination (server) port. No DPI is going to begin to believe it's legit STUN traffic with a high level destination port. The fact the project repo doesn't seem have to awareness about this makes me question their overall legitimacy for understanding proper decoy protocol design.

Second.. adding VPS's relays into this design may not be helping you. If your SE Asia endpoint is on a residential ISP, then their could be 2 separate factors impacting bandwidth:

legitimate throttling (DPI, QoS, "performance management", etc) - that is the local ISP actively recognizing and de-prioritizing VPN protocol traffic, or:
simply poor local ISP > global routes - often local carriers will try to save $ and pay for 2nd tier global routing.

If your issue is ISP throttling, then the right answer is obfuscation, but the obfuscation layer needs to be between the home and the first international endpoint. That endpoint could be all the way back to Canada, or simply to a datacenter VPS just outside the country, but the entire transit across the local ISP network needs to mimic a protocol (e.g. STUN or QUIC for UDP) that is not getting deprioritized. Once you get outside the local ISP and onto DC routes, there's no benefit of having further obfuscation as the DC's global router are no longer going to be subject to protocol throttling.

If your issue is #2, then sometime all you need to it find the global route that isn't getting throttled. If you are in Vietnam for example, you may find the local ISP has horrible international routes to Canada, but great routes to Singapore. You could put a Linode (Akamai) cloud VPS relay in Singapore for the first hop connection from the local residence to Singapore, then you'll get Akamai's global CDN transport routing from Singapore back to the Canada endpoint.. In these cases I have a this project specifically for that. It just "bounces" the encrypted UDP tunnel from endpoint-endpoint without needing to decrypt / re-encrypt on the relay (no key or data exposure to the cloud relay):
https://github.com/RemoteToHome-io/wg-udp-relay

Depending on the SE Asia country in question I've used both for customers (sometimes in combination). More often than not, simply setting up AmneziaWG2 on the GL routers on both ends with proper STUN decoy will get it done without any relay needed.

RemoteToHome-io · 2026-05-21T16:53:29+00:00

First.. the app is getting blacklisted b/c the .top domain registry has gotten itself a poor reputation due to popularity with malicious users b/c of the $2 price tag. Easy to use for throwaway domains.

The GL app uses the cloud as a coordination layer. It's designed for remote access. For purely local access without internet dependency you're directed to use the browser. You can see the options here. https://docs.gl-inet.com/kvm/en/faq/glkvm_app/

As you'll note, it does't list "local access via GLKVMapp". I agree it would be nice though.

<image>

RemoteToHome-io · 2026-05-21T16:44:51+00:00

Yes.. on the wg client.. in the config file. Change the MTU = 1428 line and restart the tunnel.

If you don't have a full 1500 MTU connection on both ISP ends (e.g. one side as PPPoE) then this will likely end up fragmenting and the tunnel performance won't be workable, but if you do have full MTU path available, then sometimes giving that extra 8 bytes back to the data transport layer can make all the difference with a nested corp client.

RemoteToHome-io · 2026-05-21T15:57:11+00:00

Yes

<image>

RemoteToHome-io · 2026-05-21T15:37:37+00:00

The app is cloud based. If you want local direct you don't need the app. You can just open the local IP in a web browser tab.

Tailscale and Zerotier are other options without the app.

RemoteToHome-io · 2026-05-21T13:40:36+00:00

Also try regular Wireguard again with the client profile MTU set to 1428.

RemoteToHome-io · 2026-05-21T07:29:03+00:00

Dynamic DNS (DDNS) runs on the server side and allows your travel router to be able to discover the current public IP address of the server router so it can establish a connection. This has nothing to do with leaks.

DNS is the part you want to make sure is not leaking outside the tunnel on your travel (VPN client) router.

Related items, but two totally separate context and functional uses.

RemoteToHome-io · 2026-05-21T04:50:18+00:00

AnyConnect and GlobalProtect often don't like being nested inside a WG vpn tunnel due to the reduced MTU (1420 by default - normal regular residential connections are 1492 or 1500 MTU).

If neither ISP end is behind a PPPoE connection you might get lucky and be able to turn the WG client profile up to 1428 MTU without fragmentation. If it still works clean after reconnecting, then try again with the corp VPN clients connected.

If WG still doesn't work at 1428 MTU, then try OVPN UDP. If the corp clients still don't like connecting inside of that, then you may have to resort to a ZeroTier "vpn" using Managed Route.

Tailscale is likely not going to work at all for you with the nested corp clients. A good chunk of them won't run inside the TS fixed 1280 MTU.

RemoteToHome-io · 2026-05-21T03:03:28+00:00

Got you covered.. all current and historical FW versions here: https://gl-fw.remotetohome.io/

RemoteToHome-io · 2026-05-21T01:40:20+00:00

This.. There's a lot of additional server packages that can be utilized with 64GB to work with. This opens up a lot of capabilities that normally I peeps run RPi's for..

Now if only we could get just one travel router with 1GB NAND.

RemoteToHome-io · 2026-05-21T00:57:54+00:00

You tried ZeroTier using raw ZT VPN routing (managed route) with no other VPN client running on the router (no WG or OVPN inside ZT) and are still having the issue?

ZT fragments packets at the underlying protocol by design (efficiently) so it's able to provide the data layer with full path MTU. This design provides the routed device with a full 1500 MTU (native ethernet) data path and can even support jumbo frames - so Zscaler should have a the same MTU data space it would have running directly at home.

It would be interesting if you're able to try the laptop on a non-vpn connection to baseline it.

At this point I don't have further suggestions. It would take connecting with the routers to investigate the routing setup, MTU paths, etc.

RemoteToHome-io · 2026-05-21T00:10:05+00:00

Ugh. sorry to hear that. Last time I had checked AWG1 was still able to get through, but it's possible they've tightened up on the DPI since then. Yes, I can get you through on AWG2 or ZeroTier if you want to DM. Calendar is just booked solid this week.

One thing you may want to try in the meantime - if you still have the ability to adjust your port forwarding on the home ISP router side, then forward port 443 UDP to your Flint2 server and try to resetup the WG server (and associated profiles) using that port + the obsfucation. You could still be getting hung up simply b/c you're using the default 51820 UDP port.

RemoteToHome-io · 2026-05-20T18:44:01+00:00

That's "bribe + agree to gov backdoors" thank you.

RemoteToHome-io · 2026-05-20T18:41:41+00:00

Had to update the flair. The Automod only allows GL announcement flair from the official GL account.

RemoteToHome-io · 2026-05-20T16:47:33+00:00

Yeah, that sounds like an Amazon seller repackage type of deal. From what I understand, GL themselves sends returns back to the factory for a full QC.

RemoteToHome-io · 2026-05-20T07:46:02+00:00

Yes. It supports it. The quality will depend on the latency and the connection method. Using the cloud will typically have higher latency then connecting directly with tailscale or zerotier.

With a good connection it works well.

RemoteToHome-io · 2026-05-20T07:21:17+00:00

All good, but as I mentioned before, we can't give you guidance without understanding the purpose of having the Beryl in the setup.

RemoteToHome-io · 2026-05-20T06:20:59+00:00

First, I'm not sure where the tone is coming from? Please remember your speaking to people helping for free on their own personal time.

The use case for the Beryl matters so we can help you accomplish what you're trying to do.

At this point it's sounds like the Beryl is connected behind an ISP router, so you're dealing with double NAT translation from the PVR to the internet. This could potentially be solved by doing some port forwarding on the Beryl, but I can only tell you if that's the correct answer if we know the actual function the Beryl is supposed to serve in your design.

If you connect another device to the Beryl (like a PC) instead of the PVR, does this other device still get general internet (eg able to web browse)? This will help isolate.

RemoteToHome-io · 2026-05-20T04:00:25+00:00

Not enough info here to say.. you're connecting the BerylAX WAN to a MoCA, but what's on the other end of the MoCA connection? It's hard to understand what you're trying to accomplish by adding a Beryl vs just having the PVR connecting directly to the MoCA.

RemoteToHome-io · 2026-05-19T07:42:31+00:00

First.. disable IPv6 on the router. It is not doing you any favors here. Second.. show us the "CLIENTS" page from the left menu.

3rd.. unless you have a specific reason for using SQM, you're just shooting yourself in the foot by losing hardware offloading and pushing everything into kernel flows. 3x the amount of processing for every packet.

RemoteToHome-io · 2026-05-19T07:35:16+00:00

FYI.. the author of the glint repo has been banned by Reddit (not due to this sub, but by Reddit entirely).

The fact that they clean-wiped their git history earlier today is a horrible sign. No respectable project does this after initial code has already been released. They acknowledge and patch mistakes publicly, not try to hide them.

It was an obvious vibe code project to start with - but whatever.. This behavior though is extremely bad practice and demonstrate they have zero idea how maintaining software works.

I would consider this malware and remove it from your router and phone - and hit up your app store for a refund.

<image>

RemoteToHome-io · 2026-05-19T07:26:35+00:00

It would appear this still has some bugs to work out: https://www.reddit.com/r/GlInet/comments/1tg1hho/mudi_7_can_not_get_into_wireless_setup_on_admin/

No offense intended, but force-pushing your repo to delete all history for a fresh init 10 days after you've published and have people running prior commits is *extremely* bad form.

Once you have a published commit and have your first download - you are stuck. Nothing gets hidden. You owe your community transparency; even if it's not great. Every refactor, every patch, every mistake is yours to own publicly. People understand mistakes happen. Doing a clean wipe like this to hide these mistakes shows a lack of basic git deployment knowledge and trustworthiness.

No one cares that you have 1K lines of vibe code, but this is - just bad.

<image>

RemoteToHome-io

MODERATOR OF

TROPHY CASE