I tried to upgrade my Slate 7 (BE3600) to version 4.10.1 from 4.9.2. Here are some of the features/settings I am using:
Starlink ISP is connected with Ethernet via a bridged Starlink router (Starlink mini).
Tailscale operating with WAN and LAN advertizing enabled. Every other Tailscale option is disabled.
Two Wireguard VPN clients have been created and are operating, both from manual configuration files from Windscribe.
Adguard Home operating with default settings other than DNS set to Windscribe dedicated DNS address. AdGuard Home Handle Client Requests option is set on.
I have changed my internal LAN scheme to 10.192.44.xx.
My Tailscale setup connects two other LANs, both are connected via Flint 2 with Tailscale running on them.
Before I upgraded, I used Luci to make a backup of my settings in 4.9.2. I then upgraded and kept my settings, like I always do.
After the upgrade, I could not connect to the internet. When I accessed the router, both VPN clients were stuck on ‘Assigning’.
The only way I could recover was to reinstall 4.9.2 and restore the settings I made before the upgrade. Everything started working again. Other posts have mentioned issues with a VPN and the new version. I camped on one or two of them, but I haven’t made a specific post about my model router and my setup.
Is this a problem with the new upgrade? Are there settings I need to change? Should I wait for the next version?
This is not yet enough to confirm a general BE3600 firmware bug. One targeted check is whether the Windscribe profiles contain an interface address such as Address = 10.x.x.x/8. If so, that /8 includes your LAN subnet 10.192.44.0/24, creating a routing overlap that may prevent the VPN from completing under 4.10.1.
You can inspect the original configuration files without reinstalling 4.10.1. If they use /8, test with a unique LAN subnet outside 10.0.0.0/8 that does not overlap either remote Tailscale LAN—for example, an unused 192.168.x.0/24. Changing the LAN subnet will disconnect local clients and require updating the Tailscale advertised route. If there is no overlap, remaining on the working 4.9.2 release while GL.iNet staff investigate is reasonable; the next useful evidence from 4.10.1 would be the redacted output of wg show, ip route, and ip rule show requested in the related thread.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
I have 3 Windscribe configurations. The Address= entries are all 100.106.132.212/32. I have a single Proton VPN configuration where the address is 10.2.0.2/32, but this config wasn’t active and was at the bottom of 3 other configs in one profile. Could this have done it?
No—the Address entries alone do not indicate an overlap. 100.106.132.212/32 does not overlap your 10.192.44.0/24 LAN, and the inactive Proton profile’s 10.2.0.2/32 also does not overlap it. An inactive profile should not establish an interface or route, so its position in the profile list is unlikely to be the cause.
The remaining relevant detail is AllowedIPs. Please check the active Windscribe profiles and the Proton profile for entries such as 0.0.0.0/0 or 10.0.0.0/8; these can install broad routes, depending on how the client/profile is handled. If the profiles use only 0.0.0.0/0 for full-tunnel operation, that is normally expected, but any 10.0.0.0/8 entry would overlap your LAN and the advertised Tailscale networks. You can share only the redacted Address and AllowedIPs lines—omit private keys and endpoint details.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
AllowedIPs = 0.0.0.0/0, ::/0 is normal for a full-tunnel VPN client and does not overlap your 10.192.44.0/24 LAN by itself. The inactive Proton profile is therefore unlikely to be the cause based on the Address and AllowedIPs values shown.
If you test 4.10.1 again, disable both VPN clients first, then enable only one Windscribe profile. This checks whether the failure occurs with a single tunnel rather than the interaction of multiple clients. If it still remains at Assigning, please send the redacted output of wg show, ip route, and ip rule show, along with the exported system log, to the staff member in the related thread by private message. Do not include private keys or full endpoint details.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
wg show doesn’t have any output. I don’t know what to redact on the output of the other commands. I don’t know what the related thread is, so I don’t know the staff member.
If wg show was run on 4.10.1 while the client showed Assigning, its empty output means no WireGuard interface existed at that moment. Please mention when you ran it—ideally within 30 seconds after starting one Windscribe profile—as this distinguishes interface-creation failure from a later handshake problem.
The related thread is Updated 4.10.0 to 4.10.1 on Flint 3 – VPN Client no longer works. Send ip route, ip rule show, the empty wg show result, and the exported log by private message to charles2, who requested those results. Click the staff member’s avatar and select Message. Do not post the full log publicly; remove any private keys, endpoint addresses, public IP addresses, MAC addresses, or serial numbers.
This reply was generated by AI. Please verify its accuracy.
GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.
I upgraded. The VPN was stuck at Assigning. I ran the commands and stored the output. I also downloaded the system log. I redacted the public key and direct message Charles2. I will then revert back to 4.9.2 and wait for a response.
The logs show that WireGuard was able to complete a handshake, but the VPN Client remained in Assigning and eventually timed out.
We also noticed that Tailscale and your Starlink WAN use the same 100.64.0.0/10 address range, with overlapping routes in the routing table.
If you're willing to test v4.10.1 again, could you please try the following?
Temporarily disable Tailscale on the router, then try connecting with your existing Windscribe VPN Tunnel. Does it still remain in Assigning?
If the issue persists, keep Tailscale disabled and temporarily disable the original VPN Tunnel in VPN Dashboard .
Then create a new Tunnel using one of your existing Windscribe WireGuard profiles, with the same routing settings. Check whether the new Tunnel can connect successfully.
After completing the tests, please export the logs again and send them to us via private message.