How Should I configure Beryl AX to avoid Tailscale DNS leak

[babaloo]

Hello,

I have a BerylAX with Tailscale routing all traffic through a Tailscale exit node (a Mac Mini).

My concern is what happens if Tailscale drops or disconnects.

I want all traffic to stop completely rather than fall back and leak through the local ISP.

I once noticed that the Beryl was showing as not connected in the Tailscale admin and am not sure about what was happening during that time.

What is the proper way to prevent DNS leaks if Tailscale disconnects on the BerylAX?

I’ve seen similar posts about kill siwthc but no clear solution that didn’t require a router as exit node.

Thanks!

[will.qiu]

Hi

In this case, you might want to use a third-party plugin developed by forum users:

Enhanced Tailscale for GL.iNet Routers (Proper TS Killswitch & one-click Exit Node)

[gl-tailscale-fix] If you use Tailscale exit node routing on a GL.iNet router for remote work or other critical IP privacy purposes, then you'll probably want to give this a read. The gl-tailscale-fix plugin closes common IP leaks on TS client routers and provides one-click functionality to use your GL router as a TS exit node. https://remotetohome.io/blog/gl-tailscale-fix/ Latest reddit discussion on the topic: https://www.reddit.com/r/GlInet/comments/1rohrna/enhanced_tailscale_for_glinet_r…

[rthco]

Thanks @will.qiu

@babaloo the plugin with provide the killswitch on the Beryl / travel router. It doesn’t matter what type of exit node it’s routing traffic to. The KS only matters on the client device side, not the server.

[babaloo]

Thank you both!.

Shortly after I turned on the custom kill switch plugin, the router hit a constant crash loop.

Following instructions (mostly from Gemini) I did the following:

• Added a USB drive to the Beryl to create a 256MB Swap partition, which stopped the OOM crash loops.

• Enabled ZRAM to optimize memory usage and keep the RAM from filling up.

Its been fairly stable so far. I’ve gone from almost no free RAM to about 250MB-290MB free, and the kill switch seems to work well.
Not sure about the actual source of the problem or if its actually related to the kill switch but I thought this feedback might be useful(?)
Thank you again

[rthco]

@babaloo Glad to hear it’s working. I’ve documented the instability extensively myself. It’s not related to the killswitch, it’s that TS runs completely in userspace (unlike native WG that runs in kernel), so it’s quite resource hungry and these 512MB GL models struggle with it. It’s expected you’ll see OOM restarts for the TS daemon. Fortunately with the killswitch you won’t be leaking your real IP until the daemon is able to restart. The reason you wouldn’t notice the OOMs before is that traffic kept flowing freely even when the daemon was crashed (out of your real IP address instead of the exit node), now with the KS, you’ll see a 8-10 second lockup of traffic until the connection is re-established.

For now, the best things you can do is:

1. disable other memory hungry services like AdGuard
2. use the plugin’s “Version Manager” function to update to the latest of @admon “TS Tiny” optimized binary, which runs more efficiently than the OEM version.