Slate AX (GL-AXT1800) Wireguard Issue (REKEY-TIMEOUT)

Technical Support for Routers
9

If it does not connect at all it is a different reason.

Should be pretty easy to find out.

Are you available to do remote check?

10

Sure - I can do that if you let me know what I you need me to do?

11

I got your email and replied that. Thanks for your help.

12

Hi, i hava same problem with GL-A1300
@alzhao can you help with it? i can send you my config in PM

13

Pls pm the wirguard config

14

I’ll reply here as this is the most recent forum post. I too have just purchased the Slate AX having previously run a slate for a long time.

Rather than just stating “I have a problem” I’ll collate some information

Current posts with a similar issue

There are 4 more, as a new user I’m limited to 2 links in a post

Personal Issue
Like many others I’m running my own WG server AND I have access to a commercial WG server. I have downloaded, copy and pasted AND manually entered configs which work fine on Linux (Ubuntu 22.04), ChromeOS, Windows and Android when used on the slate AX show the log files below. I’m confident it is not the server with the issue.

Logs

Thu Dec 29 11:47:52 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:47:57 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:48:03 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:48:08 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:48:13 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/

Firmware

  • Version4.1.0
  • Firmware Typerelease7
  • Compile Time2022-11-16 14:25:44(UTC+08:00)

Resolving Issue
It seems the only way to revolve the issue is to disable the Wireguard VPN for about 5 minutes giving the wg daemon time to shutdown then restart the wg VPN.

Log on successfully Reconnect

Thu Dec 29 11:48:16 2022 daemon.notice netifd: Interface ‘wgclient’ is now down
Thu Dec 29 11:51:35 2022 daemon.notice netifd: Interface ‘wgclient’ is setting up now
Thu Dec 29 11:51:35 2022 daemon.err tailscaled[4387]: 2022/12/29 11:51:35 LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=wlan-sta0 ifs={br-guest:[192.168.9.1/24] br-lan:[192.168.8.1/24] wlan-sta0:[192.168.68.96/22] wgclient:down} v4=true v6=false}
Thu Dec 29 11:51:35 2022 daemon.err tailscaled[4387]: 2022/12/29 11:51:35 LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=wlan-sta0 ifs={br-guest:[192.168.9.1/24] br-lan:[192.168.8.1/24] wgclient:[10.8.0.4/24] wlan-sta0:[192.168.68.96/22]} v4=true v6=false}
Thu Dec 29 11:51:40 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:51:40 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:51:40 2022 daemon.notice netifd: Interface ‘wgclient’ is now up
Thu Dec 29 11:51:40 2022 daemon.notice netifd: Network device ‘wgclient’ link is up
Thu Dec 29 11:51:40 2022 kern.info kernel: [42673.545905] IPv6: ADDRCONF(NETDEV_UP): wgclient: link is not ready
Thu Dec 29 11:51:41 2022 user.notice firewall: Reloading firewall due to ifup of wgclient (wgclient)
Thu Dec 29 11:51:48 2022 user.notice wgclient-up: env value:T_J_A1_1=object T_J_V_ifname=string USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=3 J_V_keep=1 T_J_V_ipaddr=array HOME=/ T_J_T2_mask=string HOTPLUG_TYPE=wireguard T_J_V_interface=string J_A1_1=J_T2 J_V_ifname=wgclient T_J_V_link_up=boolean T_J_T2_ipaddr=string LOGNAME=root DEVICENAME= T_J_V_action=int K_J_A1= 1 J_V_ipaddr=J_A1 TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin J_T2_mask=24 CONFIG_LIST_STATE= J_V_interface=wgclient K_J_V= action ifname link_up keep ipaddr interface J_V_link_up=1 J_T2_ipaddr=10.8.0.4 J_V_action=0 N_J_V_link_up=link-up PROTO_IPADDR=10.8.0.4/24// T_J_V_keep=boolean PWD=/ JSON_CUR=J_V K_J_T2= ipaddr mask CONFIG_SECTIONS=global AzireVPN Mullvad FromApp group_2911 group_5878 group_5196 group_9171 peer_2634 CONFIG_cfg030f15_ports=
Thu Dec 29 11:51:48 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/

Current Stance
The stance from the support team here appears to be that they cannot replicate the issue and as such they cannot resolve the issue which I understand (I’ve supported several dev teams over the years) If however this is the case you need to do the following

  1. Improve your logging so the above is not the case
  2. Add a function somewhere to pull out the information you need not in the logging.

Not being able to replicate an issue which is seen across several of your products (links above as proof) is not a good enough reason not to be fixing it. If you don’t have the data to fix it, that is in your hands to produce the GUI to provide it.

Required Action

  1. Post here what you need from people who are having the same issue? Logs, other data?
  2. Is there any testing people can do?
  3. Provide a timeline of what happens next

Conclusion
Since the 4.x upgrades there is a problem with the WG client, this needs to be resolved.

4 Likes
15

You’ve done the reconnect in 3 Seconds?
This is the time between unsuccessful last message and successful first message.

Could it be a time issue?
I read a lot about this here, too, but I can’t confirm. I am moving in only one timezone. And set it right is the first action after every reset.

2 Likes
16

Thanks for your info.

Yes I take your advise and working on a solution, e.g. more logs etc.

I just want to say again that the most of REKEY-TIMEOUT is just the server is not available.

If users cannot just say I have the same problem, rather give some decriptions like you, it will be much helpful.

3 Likes
17

I did a further deep dive to the underlying network this morning, and while my Wireguard server was working OK, I’m now tending to agree with you (at the moment) that the REKEY-TIMEOUT isn’t related to the Wireguard server its related to the underlying internet connection having an issue.

I was connected to an AirBnB wifi and was getting consistent dropout of wireguard, (approx every 10 minutes) when I connected the Slate AX to my Mobile phone hotspot I got a consistent connection. (no dropouts)

Personally I’d like to see maybe an Uptime Kuma (GitHub - louislam/uptime-kuma: A fancy self-hosted monitoring tool) style UDP poll to the wireguard server and an associated ping test maybe to a custom location.

This at least starts a correlation between the Wireguard server and general internet uptime.

I’m not 100% convinced there isn’t an issue (probably on OpenWRT side) and will give you any testing / feedback you need to assist.

1 Like
18

Thats poor logging, not factual. When you turn off the Wireguard VPN the log doesn’t register it as turned off, not until its started again does the log file state its taken down the Wireguard connection (hence the 3 seconds) I noted this last night.

I have put some further test notes below in the page.

Its not timezone related, I tested that…

2 Likes
19

In my case, I’m having this issue when I try to use a Wireguard VPN with USB tethering (Android phone).
VPN works fine with a normal Ethernet WAN connection, but if I try to switch to USB tethering, I get the endless “REKEY-TIMEOUT” logs.

Problem is, this worked fine in version 4.0.3. I upgraded to version 4.1.0 (just to get rid of the yellow dot in the UI), and it stopped working. I rolled back to 4.0.3, but it never worked again.

VPN works fine with a normal Ethernet connection, and the router also works fine with USB tethering without VPN turned on.

20

I don’t think this is related to firmware version.

Maybe try change Wireguard MTU and test.

21

I have never needed to change the MTU size to get the VPN working. I already tried changing the MTU size manually, but as expected, that didn’t make a change. Additionally, my VPN provider (StarVPN) does not recommend setting the MTU manually.

Here’s the situation:

Scenario 1: VPN off, router connected to my home Internet connection - Working
Scenario 2: VPN on, router connected to my home Internet connection - Working
Scenario 3: VPN off, router connected to Android device with USB tethering - Working
Scenario 4: VPN on, router connected to Android device with USB tethering - Not working

Additionally:

Router came with firmware 4.0.3 preinstalled → Scenario 4 was working
I upgraded to firmware 4.1.0 → Scenario 4 stopped working
I downgraded to firmware 4.0.3 → Scenario 4 still not working.
Reset back to factory settings → Scenario 4 still not working

Happy to share my Wireguard config file if this is needed.

22

You can share to me. But ustually carrier network and vpn issues are related to mtu.

I can have a try on my iPhone tethering but not sure if I can met the same problem.

23

I mean…it worked with the pre-installed 4.0.3 firmware, and I used the VPN for about ten minutes. I even turned on/off my Internet connection on the Android device to confirm that it was actually getting connectivity from USB tethering. Problems started as soon as I upgraded to 4.1.0.

Android device is connected to the same Internet connection as in scenario 1 and 2, so this is not a carrier network issue.

How do I share it to you? Can you provide an email?

24

So the Android is actually connecting to your wifi and share to via USB?

Just share with PM.

25

Correct. Android is connected to wifi. However, before upgrading to 4.1.0, it worked with both Wifi and Mobile Data.

Everything (all four scenarios) was working with the pre-installed 4.0.3 firmware. Issues started by upgrading to 4.1.0

26

Did you keep settings when you revert back from 4.1.0 to 4.0.3?

If you didn’t keep settings then it should not relate to firmware version.

27

I did keep the settings. The Wireguard config is in place.

28

Pls try clean installation and Configure again.