@rthco - It’s a fairly new device and I’m still struggling which GL.iNet product belong where on my network, with the Brume 3 probably being the most obvious and yet the most awkward one, so I’ve done very little with it since I made it the “entry” point of the network, replacing one of the 3*Flint 3 (which replaced 3xFlint 2). With Flint 4 “Coming soon” and 10Gbps ports (and God, give us finally a proper mesh!!!), I’d find the Brume 3 even more awkward with its 2.5Gbps ports, doing what… not sure.
Having said all that useless for the upgrade “stuff”, I could just reinstall, as per your suggestion.
Or, if you want to see what went wrong and troubleshoot more, keep digging in the name of 1.0.21 come out even more perfect.
@Marv thanks for the offer. I’ve added some extra test cases to my local .21 repo that I should be able to catch it. I’d love to dig, but free time is at a minimum rn.
As far as the Brume3.. it is an interesting case. I have a lot customers using them as just a dedicated VPN appliance. They just hang it off the back of their main router and forward a few ports.
Making proper use of the LAN ports (and all the DPI, etc) is a bit more niche specific. The easiest home use-case would be the have it as the primary gateway and just attach a wifi AP.
Recommended update for gl-tailscale-fix plugin users. The new v1.0.21 update includes improvements to the Kill Switch, IPv6 routing and GL 4.9 compatibility. Full release details here: https://remotetohome.io/blog/gl-tailscale-fix/#update-v1021
Important behavior change to be aware of - the plugin's Kill Switch no longer disables automatically when disabling Custom Exit Node routing. This is to both increase security as well as now allowing a user to safely swap between exit node IPs or even temporarily disable exit routing to make other changes (binary updates, etc) with zero leak risk to attached clients.
Other improvements include updates to ensure IPv6 IP Masq, improved compatibility with recent GL 4.9+ firmware TS updates and "in-place" plugin updates with active tunnels.
Plugin update process: https://remotetohome.io/blog/gl-tailscale-fix/#installation
Curious how hard would it be to get the exit node/updating feature to the gl inet kvms running tailscale as they also support the exit node function (and behind on updates)
@rthco I’ve got 2 Flint 3’s set up with Tailscale for a site-to-site network. One issue I’m having is that despite IPv6 being enabled and configured (seemingly) correctly on both routers, the v6 LAN subnet routes aren’t being advertised to Tailscale. Checking the gl_tailscale script (with Claude’s help–I’m not a SW engineer) it appears that the script never even looks for v6. I was hoping that was included in your fix, but it doesn’t seem to be the case. I’m working on a separate script to add those routes via set using a hotplug and/or cron job. Is that the best approach, or is something just not configured correctly? Firmware version info and uci outputs for both tailscale and your plugin are below.
@OddZilla thank you for the detailed bug report.. Can you verify which version of the gl-tailscale-fix plugin you’re running? If not already, then please try v1.0.21 as there were some other subtle ipv6 fixes bundled. If you’re already on v.21 and still seeing this, then I can troubleshoot further.
EDIT - Actually.. I just thought about it more and you’re right.. we have IPv6 to the router - but not for LAN clients behind the router. I’ll eval adding this in the future.
The one thing to consider in your plan is “tailscale set --advertise-routes= “ is a replace, not an add. If your script sets just the v6 prefix, it will wipe the IPv4 LAN route GL advertised. You’ll want an approach that picks up IPv4 and write an IPv6 append with proper ordering.
I’ve have a lot packed into v22 right now (close to drop), but I’ll put it for eval in v23.
@rthco Thanks for the quick reply. I am running v.21. I was able to get a working config using a small script and hotplug that runs 30 seconds after a reboot and cron job running every 5 min (probably overkill to run it that often). The script handles both ipv4 and v6 addresses.
@Lastimosa That error is expected when going through the admin UI on op25 fw. GL LuCI uploader runs a plain “apk add” and o25 won’t accept a package not signed by a trusted key. The op25 build is currently unsigned like the regular GL firmware version. You can install via SSH on the router with:
