Last week I purchased two GL – SF 1200 routers from GL’s website. I opened one of the routers and configured it with Wireguard client after upgrading the firmware to 3.204. It connected successfully and I browse the Internet with it for about an hour. I checked the IP and found out that the VPN was working as it should’ve been. Later that day I powered down the router and did not powered back on for two days. When I did powered on the VPN Wireguard client failed to successfully connect to my VPN provider. I tried to connect several times but without success. I use Keepsolid Unlimited as my VPN provider. I downloaded two more configuration files from two different servers and manually install them as well. I was not able to connect with either one of them and the original unchanged client still did not work. I saw similar post on this forum from people who experienced somewhat the same problems but from different VPN providers. I hope someone can shed a light on this problem. I personally think it’s a firmware problem but that’s just my opinion. I had a similar problem from a GL Travel router purchased from Amazon. GL.iNet GL-AR300M Mini VPN Travel Router, Wi-Fi Converter, OpenWrt Pre-Installed, Repeater Bridge, Hotspot, 300Mbps High Performance, 128MB Nand Flash. I returned it as defective but now I have a repeat of the same problem. The travel router worked once as a Wireguard client and failed to work again when when re connected after powering down. I have been told it could be a time sync issue but I do not know how to change it. I am using GL GUI but I cannot find out how to change the time in luci. Do I have to return the router to default and start over or is there some way to change the time in luci. I am not that familiar with openwrt and I am just getting started.
I took the router back to factory default and started from scratch. I synced the time with my browser and then I I went to KeepSolid and created a brand new wireguard config file. I created a config for a server in Illinois and connected the wireguard client and it worked. I also installed an earlier config from Washington but did not renew it on Keepsolid. I ran the old config for Washington and I experienced the same abort issue. I then tried the new Illinois config and bingo—it connected. I am writing this post using my Illinois VPN connection.
Following advice from the GLInet forum “Keepsolid is that their Wireguard is a bit flaky - your configurations may change without notice and will need to be regenerated in your management panel”
I can’t say for sure I solved the problem if I power down the router but for right now I am connected.
I am going to not power down this router for a few days and see if I loose the connection or not or if the problem re-surfaces.
Perhaps you don't understand, but syncing time once in not enough.
If your router is missing RTC, then time will desync sooner or later depending on the hardware.
And this can lock the VPN connection until you manually set client time forward or restart the server.
That's why you need to implement one of the workarounds mentioned above.
fwiw, this is something I have observed with Keepsolid when I briefly tested Wireguard last year. Wireguard would always stop working the following day when the router was turned off overnight. Time sync wouldn't fix the problem, I had to regenerate a new config to resolve it each time. I speculate they may have implemented some sort of inactivity timeout mechanism. I returned to using OpenVPN.
However, for the past fortnight, I am currently testing Wireguard again for one particular location. Apart from one incident where I had to regenerate the config, the two different model routers (19.07.7 and 20.02.0-rc4) continue to work after being powered off for one or two days. I can confirm only one router (a HH5a) needed the time sync/Race Condition fix.
I note the two Wireguard servers have different IP addresses. I'm not confident the configs on both routers will continue to work in the months to come, unlike Keepsolid's OpenVPN which uses hostnames and is far more reliable.
I am trying to implement this solution but I am not sure how to proceed. This is done through Luci and is implemented through the startup tab under System Tab Local Startup Tab:
Local Startup
This is the content of /etc/rc.local. Insert your own commands here (in front of 'exit 0') to execute them at the end of the boot process.
These commands are here already. Where do I insert the script in this. I did not enter these scripts as it appears they were generated by the router during setup.
type or paste code here
autoupdate=$(uci get glconfig.autoupdate)
[ -z "$autoupdate" ] && {
uci set glconfig.autoupdate=service
uci set glconfig.autoupdate.time='04:00'
uci set glconfig.autoupdate.enable='0'
uci commit glconfig
}
samba=$(uci get glconfig.samba)
[ -z "$samba" ] && {
uci set glconfig.samba=service
uci set glconfig.samba.read_only='yes'
uci commit glconfig
}
/usr/bin/glautoupdater &
#(sleep 15;/usr/bin/gl_health) &
# VIXMINI should turn of system led after boot is successful
if [ "$(cat /tmp/sysinfo/model)" = "VIXMINI" ]; then
echo 0 > /sys/class/leds/vixmini\:blue\:power/brightness
fi
if [ "$(cat /tmp/sysinfo/model)" = "microuter-N300" ]; then
echo 0 > /sys/class/leds/microuter-n300\:blue\:power/brightness
fi
killall uqmi
traffic=`uci get glconfig.traffic_control.enable 2>/dev/null`
if [ "$traffic" == "1" ];then
uci set tertf.general.cleartraffic='1'
uci commit tertf
fi
/etc/init.d/gl_ipv6 reload 2>/dev/null
"This is the content of /etc/rc.local. Insert your own commands here (in front of 'exit 0') to execute them at the end of the boot process." As far as I can tell there is no 'exit 0' is the startup.
Does this mean I paste the script at the end of the existing script or at the beginning? I am new to Openwrt and do not fully understand the Luci interface.
Looks like you are using a gli-net device using their firmware and not an official openwrt build, is that correct? If so, you should ask gli-net or on their forums since they use a customized version of openwrt that is sufficiently different as to require different solutions.
You are correct. I am using a gli-net device. I am considering flashing a new TP-Link Archer C7 version 5 router with the latest OpenWrt firmware but I have not done that at this point.
I have posted my problem on gli-net forum and sent a request to customer support for gli-net help but so far I have not received a solution. I'm new to Openwrt. I am using the firmware that came on the device and only used the GUI of the GL – SF 1200 router. I did install Luci but I do not know much about it. At this point I am trying to solve the problem with the router firmware.
If you flash an official version of OpenWrt, we will be able to help you on this forum. However, as long as you are using the customized versions supplied by other manufacturers, we can do little more than guess.
Thank you---I understand this is a GL-iNet problem. If I decide to flash my TP-link router I will reach out to the forum again if I find something I do not understand.
Sounds good. Please understand that this isn't an unwillingness to help, but rather that there are just so many potential differences in the way that the gl-inet firmware works compared to official OpenWrt that the advice you might get here could even lead you in the wrong direction or on a wild goose chase. Hopefully you'll get some answers over at the gl-inet sites, but if not, give OpenWrt a try and come here so we can help answer any questions you might have.
