VPN Not loading on GL-A1300 Slate Plus

Router
1

I have a Slate Plus GL-A1300, it was running without issues, now It wont load the VPN, I was using Wireguard, and also have tried Nord same issue, All I get is the same message, Client is loading, please wait. But it never loads and the connection times out. Any suggestions?

I have reset the device and still the same issue,

2

Because both WireGuard and NordVPN remain on “Client is loading, please wait”, first determine whether this is a cached Admin Panel issue or the router’s VPN service:

  1. Connect locally to the Slate Plus, reboot it, then open http://192.168.8.1 in a private/incognito window or another browser. If that works, clear the browser’s site data for the router address.
  2. If the VPN page still does not load, please provide the router’s firmware version and confirm whether other Admin Panel pages open normally. This will distinguish a VPN-service issue from a broader Admin Panel/backend problem.

Do not factory-reset the router yet, as that would erase its configuration.

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.

3

The firmware version is 4.5.22, and the admin window opens normally. I have tired both openvpn and wire and both do the same thing: the message The client is starting, please wait. And then the connection times out

4

Because both OpenVPN and WireGuard fail while the Admin Panel itself works, test whether the problem is specific to the current Internet connection:

  1. Connect the Slate Plus to a phone hotspot in Repeater mode, then try the VPN again. If it works on the hotspot, the original network or upstream DNS/firewall is blocking or interfering with the VPN connection.
  2. If it still fails, go to Network → DNS, select Manual DNS, set 8.8.8.8, apply the change, and retry. Also check System → Time Zone and make sure the router’s date and time are correct, since an incorrect clock can prevent VPN authentication.
  3. Check System → Upgrade for the latest official firmware available for the GL-A1300. If the problem remains after the hotspot test and DNS/time checks, please report the result of each test and whether the router can reach ordinary websites while connected to the original network.

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.

5

The repeater is up and running, i show the Slate plus connected to my phones hotspot, but i cant access 192.168.8.1

6

The device opening the Admin Panel must be connected to the Slate Plus LAN/Wi-Fi, not directly to the phone hotspot. If the same phone is providing the hotspot, use another phone/computer connected to the Slate Plus Wi-Fi, or connect a computer to its LAN port, then open:

  • http://192.168.8.1
  • If that fails, try http://router.gl-inet.com

Confirm that the connected device received an address beginning with 192.168.8.. If it received a different address, forget and reconnect to the Slate Plus Wi-Fi, ensuring mobile data or another active network connection is temporarily disabled.

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.

7

Getting the same message the client is starting, please wait

8

Since the VPN still shows “Client is starting, please wait” while the Slate Plus is connected through your phone’s hotspot, the original Internet connection is unlikely to be the cause. The next useful step is to capture the router’s log after reproducing the problem:

  1. Connect a computer or another phone to the Slate Plus, open http://192.168.8.1, and start one VPN profile.
  2. After it times out, go to System → Log and use Export.
  3. Share the exported log or a redacted excerpt here. Please remove passwords, private keys, tokens, and public IP addresses.

Also check System → Upgrade for the latest official GL-A1300 firmware available. Firmware 4.5.22 is quite old; if an upgrade is available, back up your settings first, install it, reboot the router, and test one fresh WireGuard profile before trying the other VPN profiles.

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.

9

Firmwave version is 4.5.22 upgrade indicates firmware is up to date.

Here is the log files

Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Rule 'wan_in_conn_mark'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Rule 'lan_in_conn_mark_restore'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Rule 'out_conn_mark_restore'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Zone 'lan'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Zone 'wan'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Zone 'guest'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Zone 'ovpnclient'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Set tcp_ecn to off
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Set tcp_syncookies to on
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Set tcp_window_scaling to on
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Running script '/etc/firewall.nat6'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Running script '/etc/firewall.swap_wan_in_conn_mark.sh'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Running script '/var/etc/gls2s.include'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): ! Skipping due to path error: No such file or directory
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Running script '/usr/bin/gl_block.sh'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): * Running script '/etc/firewall.vpn_server_policy.sh'
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): Failed to parse json data: unexpected character
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): uci: Entry not found
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): cat: can't open '/tmp/run/ovpn_resolved_ip': No such file or directory
Tue Oct 6 09:17:00 2026 daemon.notice netifd: ovpnclient (18070): cat: can't open '/tmp/run/ovpn_resolved_ip': No such file or directory

10

The excerpt does not show the OpenVPN connection or authentication error. However, ovpn_resolved_ip: No such file or directory suggests the VPN server hostname may not have resolved. Please confirm the DNS test that was requested earlier: go to Network → DNS, select Manual DNS, set 8.8.8.8, apply it, and retry one VPN profile.

If it still times out, reproduce the issue and provide only the log lines containing openvpn, ovpnclient, wireguard, wgclient, or vpn, including roughly 20 lines before the first error. Redact server addresses, public IPs, credentials, tokens, and keys. Those lines should distinguish name-resolution failure from a VPN service/configuration failure; the firewall initialization lines shown here are not sufficient to determine that yet.

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.

11

Wireguard log files, same issue,

DNS set to 8.8.8.8

Tue Oct 6 09:23:30 2026 daemon.notice netifd: Interface 'wgclient' is setting up now
Tue Oct 6 09:23:30 2026 daemon.notice netifd: wgclient (32340): Error: any valid prefix is expected rather than "".
Tue Oct 6 09:23:30 2026 daemon.notice netifd: wgclient (32340): Error: inet6 prefix is expected rather than "#".

12

These errors occur before any WireGuard handshake, so DNS and the VPN server are not the immediate cause. They indicate that the router is receiving an empty or malformed IP-prefix value; the "#" error may come from a comment or incorrectly parsed line in the profile.

Delete this WireGuard profile, download a fresh configuration from the provider, remove any comment lines beginning with #, and import it again. Verify that Address and AllowedIPs contain valid CIDR prefixes—for example, Address = 10.x.x.x/32 and AllowedIPs = 0.0.0.0/0, ::/0—with no blank entries or inline comments. If it still fails, post only the sanitized Address, DNS, AllowedIPs, and Endpoint lines, redacting the endpoint hostname/IP but retaining its port and punctuation. Do not post any private or preshared keys.

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.

13

Tue Oct 6 09:23:30 2026 daemon.notice netifd: Interface 'wgclient' is setting up now
Tue Oct 6 09:23:30 2026 daemon.notice netifd: wgclient (32340): Error: any valid prefix is expected rather than "".
Tue Oct 6 09:23:30 2026 daemon.notice netifd: wgclient (32340): Error: inet6 prefix is expected rather than "#".
Tue Oct 6 09:25:19 2026 daemon.notice netifd: Interface 'wgclient' is now down
Tue Oct 6 09:25:19 2026 user.notice firewall: Reloading firewall due to ifdown of wgclient ()
Tue Oct 6 09:31:04 2026 daemon.notice netifd: Interface 'wgclient' is setting up now
Tue Oct 6 09:31:04 2026 daemon.notice netifd: wgclient (3049): Error: any valid prefix is expected rather than "".
Tue Oct 6 09:31:04 2026 daemon.notice netifd: wgclient (3049): Error: inet6 prefix is expected rather than "#".

15

Hi,

Thank you for sharing the additional logs and testing results.

We noticed some IP prefix parsing errors in the WireGuard logs, which may be related to the VPN configuration or its initialization process.

Could you please share your current WireGuard configuration (remove the PrivateKey and PublicKey.) with us via private message?
Additionally, could you please try generating and importing a completely new WireGuard configuration to see if the same issue persists?
If possible, could you also export the complete system logs from SYSTEM → Log after reproducing the issue and send them to us via private message?

Thank you for your patience and cooperation.

How to export logs:

image
image1430×911 87 KB

How to send private messages:

image
image471×172 13.5 KB