I am using Beryl firmware version v4.1.0 as wireguard vpn server. I have setup the listen port at 51830 and did the port forwarding correctly as well. I downloaded the config file and setup the wireguard client directly with .conf file at Slate Ax running at firmware v4.2.1.
Previously i was running the Beryl at version 3 and everythin was working fine. I had the vpn server up and running at port 51820 and client was also able to connect to server without any issues. But yesterday i had the power down on internet and my ISP changed the public ip, but my server was using DDNS and i had the setup correctly at the client side also. Somehow, the client was not able to connect and just stuck at “waiting for the client”. So i upgraded the framework at Beryl to v4.1.0 and setup a new vpn server and all. But now i am not able to connect to server with Slate AX and getting these logs error:
Sat Jun 3 12:53:25 2023 daemon.notice netifd: Interface ‘wgclient’ is setting up now Sat Jun 3 12:55:12 2023 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-GIVEUP SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/ Sat Jun 3 12:55:12 2023 daemon.notice netifd: Interface ‘wgclient’ is now down Sat Jun 3 12:55:12 2023 daemon.notice netifd: Interface ‘wgclient’ is setting up now Sat Jun 3 12:55:12 2023 user.notice mwan3[7195]: Execute ifdown event on interface wgclient (unknown) Sat Jun 3 12:55:13 2023 user.notice firewall: Reloading firewall due to ifdown of wgclient ()
My config file for Beryl VPN server looks like this:
[Interface]
Address = 10.0.0.2/24
ListenPort = 19246
PrivateKey = **********
DNS = 64.6.64.6
MTU = 1420
I did the steps again setting up the vpn server with port 51820 and it worked again. I can now connect with slate vpn client. DDNS was showing my correct public IP. Thanks!!
But still i want to know as why after internet connection got interrupted the vpn server just stopped working. After the interruption my public ip got changed also but ddns was showing correct ip. What measures could i take if something like this happened again?
So it seems a problem when change port. The new port 51830 seems not open for some reason. It could be a bug or wrong operation, not sure. But generally using the default config is safe
Hi, I am having the same issue with my Slate AX (Client) and Beryl (Server) setup. I am on firmware v4.2.1 on the AX. I tried all 3 steps you provided but it did not work for me. I also rebooted the devices several times. I have checked and my time zones are the same for both devices.
This is the config I am using:
[Interface]
Address = 10.0.0.2/32
ListenPort = 59703
PrivateKey = ***
DNS = 64.6.64.6
“Thu Jun 8 22:01:15 2023 user.notice firewall: Reloading firewall due to ifdown of wgclient ()\nThu Jun 8 22:02:58 2023 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-GIVEUP SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/\nThu Jun 8 22:02:58 2023 daemon.notice netifd: Interface ‘wgclient’ is now down\nThu Jun 8 22:02:58 2023 daemon.notice netifd: Interface ‘wgclient’ is setting up now\nThu Jun 8 22:02:58 2023 user.notice mwan3[7466]: Execute ifdown event on interface wgclient (unknown)\nThu Jun 8 22:02:59 2023 user.notice firewall: Reloading firewall due to ifdown of wgclient ()\nThu Jun 8 22:04:42 2023 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-GIVEUP SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/\nThu Jun 8 22:04:42 2023 daemon.notice netifd: Interface ‘wgclient’ is now down\nThu Jun 8 22:04:42 2023 daemon.notice netifd: Interface ‘wgclient’ is setting up now\nThu Jun 8 22:04:43 2023 user.notice mwan3[11857]: Execute ifdown event on interface wgclient (unknown)\nThu Jun 8 22:04:43 2023 user.notice firewall: Reloading firewall due to ifdown of wgclient ()\nThu Jun 8 22:06:25 2023 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-GIVEUP SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/\nThu Jun 8 22:06:26 2023 daemon.notice netifd: Interface ‘wgclient’ is now down\nThu Jun 8 22:06:26 2023 daemon.notice netifd: Interface ‘wgclient’ is setting up now\nThu Jun 8 22:06:26 2023 user.notice mwan3[16142]: Execute ifdown event on interface wgclient (unknown)\nThu Jun 8 22:06:27 2023 user.notice firewall: Reloading firewall due to ifdown of wgclient ()\nThu Jun 8 22:07:42 2023 daemon.notice netifd: Interface ‘wgclient’ is now down\nThu Jun 8 22:07:43 2023 user.notice mwan3[19729]: Execute ifdown event on interface wgclient (unknown)\nThu Jun 8 22:07:44 2023 user.notice firewall: Reloading firewall due to ifdown of wgclient ()\nThu Jun 8 22:08:21 2023 daemon.notice netifd: Interface ‘wgclient’ is setting up now\n”
I think I can answer that: after your client connects to the server via ddns in the WG configuration, that endpoint is cached once by the wgclient interface as a IP… so even though the ddns provider might be updated as expected when your dynamic IP changes after that connection/tunnel is established, your client’s wg endpoint (to the server IP) can become stale. It’s a reason PersistentKeepalive = 25 is important: WG is a ‘stateless’ protocol… so wgclient sometimes can become ‘out of sync’ as WG itself has no way of knowing the server IP has changed with that keepalive period.
Strictly from wgclient’s perspective it’d be like someone constantly sending mail to your (old IP) address but you’ve already move (to a new IP) & didn’t tell’em a forwarding address.
root@GL-AXT1800:~# wg show
interface: wgclient
public key: 24[REDACTED]7L=
private key: (hidden)
peer: +7P[REDACTED]H2=
endpoint: 208.78.41.97:51820
allowed ips: 0.0.0.0/0
latest handshake: 18 seconds ago
transfer: 32.24 KiB received, 16.13 KiB sent
persistent keepalive: every 25 seconds
Servers, as they relate to Enterprise operations, don’t often change their forward/public facing IPs. That still doesn’t help us though. Manually disconnecting, reconnecting Client to force a new tunnel to Server is the ‘quick & dirty’… until it happens again. Wash, rinse, repeat.
I’m currently getting into position for a WG-based project using GL’s hardware that includes addressing this very issue. If there’s any interest in this thread for it, I’ll see about posting what I have in mind as a solution for it here or linked elsewhere.
