Slate AX 1800 - VPN connectivity

hi there,

I have 2 Slate AX routers which I’ve setup and connected via Wireguard VPN. I had no issues for 2 months when I was using both from the same country. I travelled, and the VPN connection was still working fine for about a month and then it stopped working. 2 weeks later it was working again with no intervention of mine, but it stopped working again few days ago.

I’ve reset the router to manufacturer’s settings and did repeated the process to set it up but no luck! I am suspecting the country I’m in currently is actively blocking VPN tunnels, for example, I can’t even get on the most popular VPN websites such as NORD VPN. I am hoping to see if anyone else had a similar problem and there is a fix. Below is the error log. Note: I’ve removed listen port to blank, increased keep alive to 120, but neither tweaks worked.

appreciate any help from the community!

Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: * Zone ‘lan’
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: * Zone ‘wan’
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: * Zone ‘guestzone’
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: * Zone ‘wireguard’
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: * Set tcp_ecn to off
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: * Set tcp_syncookies to on
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: * Set tcp_window_scaling to on
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: * Running script ‘/etc/firewall.user’
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: uci: Entry not found
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: uci: Entry not found
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: uci: Entry not found
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: iptables: No chain/target/match by that name.
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: iptables: No chain/target/match by that name.
Tue Aug 1 11:05:26 2023 daemon.err gl_monitor[3924]: ipset v7.3: The set with the given name does not exist
Tue Aug 1 11:05:27 2023 daemon.err gl_monitor[3924]: iptables: No chain/target/match by that name.
Tue Aug 1 11:05:27 2023 daemon.err gl_monitor[3924]: * Running script ‘/var/etc/gls2s.include’
Tue Aug 1 11:05:27 2023 daemon.err gl_monitor[3924]: ! Skipping due to path error: No such file or directory
Tue Aug 1 11:05:27 2023 daemon.err gl_monitor[3924]: * Running script ‘/usr/bin/glfw.sh’
Tue Aug 1 11:05:27 2023 daemon.err gl_monitor[3924]: * Running script ‘/usr/sbin/glqos.sh’
Tue Aug 1 11:05:29 2023 daemon.err gl_monitor[3924]: /sbin/uci: Invalid argument
Tue Aug 1 11:05:29 2023 daemon.err gl_monitor[3924]: /sbin/uci: Invalid argument
Tue Aug 1 11:05:30 2023 user.info mwan3rtmon[3215]: Detect rtchange event.
Tue Aug 1 11:05:30 2023 daemon.err gl_monitor[3924]: uci: Entry not found
Tue Aug 1 11:05:30 2023 user.notice wiregaurd: client start completed, del glwg.lock
Tue Aug 1 11:05:30 2023 daemon.err gl_monitor[3924]: uci: Entry not found
Tue Aug 1 11:06:37 2023 user.notice wireguard: wireguard client stop
Tue Aug 1 11:06:38 2023 daemon.info dnsmasq[25069]: exiting on receipt of SIGTERM

With Wireguard, you might have some luck with switching to a popular UDP port like 443 or 53, if your VPN provider supports these. There’s a chance they might not be blocked.

Alternatively, try OpenVPN. It can send traffic via TCP 443, so even lower chance of blocking. Some VPN providers, like AirVPN, also have options like tunnelling OpenVPN through SSL or SSH. This can’t be pretty much stopped by censorship, but slows things down.

Thanks! Openvpn is extremely slow especially due to the geographic locations of server and cient. UDP changes didnt work

Hello again, any ideas based on the error log whether in fact it is blocked by the government? Any help would be greatly appreciated

You can try UDP 443 as well, it’s been introduced by http/3.

Yes, it could work as well, but I’ve been to places where UDP 443 is blocked. Maybe getting it to work with TCP 443 would be a good start to make sure everything else works.

It’s pretty new, yes. But you usually want vpns on udp. I’d go with 53 as you suggested.