Wireguard server DDNS "Name does not resolve"

Technical Support for Routers
1

Hello. I've got a Brume 2 on a different continent serving as a Wireguard server (behind a host-country ISP modem that's correctly set to port forward to the Brume 2 - I double-checked as my ISP allows to set port forwarding remotely).

I noticed that while my existing Beryl AX client was connected just fine (suggesting the client, server, and ISP are all working properly), my Android phone suddenly couldn't create a new tunnel with the Brume 2 server due to DDNS (at glddns.com) not resolving.

I went ahead and remotely restarted the home-country ISP modem, double-checked that it still correctly port forwards to the Brume 2 server, but now even my Beryl AX client cannot re-create a VPN connection with that Brume 2 server. It is giving me the following error in the log next to my dnss address:

"Name does not resolve"

My setup has been working as is for about a year up until now, with no changes to the configuration, so this issue is coming out of nowhere.

Is there an issue with the Gl-inet DDNS server? Your status website does not list issues. But while all the hardware appears to work on my end with no configuration changes made, new DNS resolution calls suddenly aren't going through, so I cannot reconnect to my VPN tunnels if they aren't already connected.

I am unable to access the Brume 2 server until December 2025 to do anything or pull logs, except to ask a family member to travel to its physical location and restart the thing :frowning:

2

Please check if the DDNS address is still correct and gets resolved around the world. Check using https://dnschecker.org/

If it isn't the case it might be necessary to disable and re-enable DDNS on the router. If GoodCloud is enabled on it, you can use it to get to the web UI.

3

I've entered my dnss address and got red crosses in all tests :face_holding_back_tears:

  1. Why would this happen? Why would the Gl-inet dns server spontaneously drop my address that worked just fine for the year up until now?
  2. Is there anything else that can be done?
    Sadly, I don't have GoodCloud or access to the server unless I take a $1500+ unplanned trip seemingly just to flip a switch. I take it standard resets aren't goint to fix it? They're running on a monthly schedule. I'm not sure if I should wait, or spend that money on a long journey to the server.

I expected temporary issues which I can overcome with a private VPN temporarily, but not a permanent dramatic fail like this to happen on its own.

4

A reboot might fix it, if GLDDNS is still working in general. You might need to wait then.

Other way I could think of: Trying to find the current IP by looking up some logs (maybe you have devices there that might connect to services?)

I highly recommend to enable GoodCloud as soon as your device is reachable again.

Maybe @bruce can retrieve the old IP if you send him the DDNS name.

1 Like
5

Thanks to my ISP's app I got the IP address of my ISP modem, I took the Brume 2 (server's) port number from the config file, and I was able to use that combo to create a tunnel!

This is not a long-term solution, as that IP will eventually change (hence why I used DDNS).

Is there a way I can re-enable DDNS from there? I remember disabling remote access to the control panel on that Brume as it was deemed unsafe :smiling_face_with_tear:

6

If the tunnel is up and running you can access the brumes UI by it's LAN IP. Pretty sure you did not disable this.

1 Like
7

Sadly, it looks like I have, as putting the Brume 2's LAN address in the browser makes it time out and not connect to the admin panel :smiling_face_with_tear:
I can't ping it either.

Thanks @admon for your suggestion to dig up the IP and use it to create a tunnel instead of DDNS. It's the best temporary band-aid fix for my issue.

Looks like unless this is properly addressed (by someone from GL Inet on their DDNS side), or the Brume 2 does something to fix itself, I'll be stuck relying on the ISP's dynamic IP not changing too often.

Edit: it did in fact "fix itself". The scheduled restart brought DDNS back alive. Which is amazing news for me. But for other users who may be running into this issue (that seemingly came out of nowhere, and I don't know the cause of), I just wish the devices re-tried enabling DDNS automatically over time after the initial failure.

8

The restart fixed it. Thanks for your help. I was super lucky to set the scheduled reset. The topic can be closed for posterity :slight_smile:

I just wish the devices re-tried enabling DDNS automatically over time after it fails.

9

Thanks for the update.

It's possible that the public IP address has changed, but DDNS hasn't time to update it.
If your router glddns domain name can't be resolved, you can try waiting for a few minutes to let it update again and see if it works later. If not, you can also off/on the DDNS service.

If you continue to have trouble resolving the domain name, please PM me your glddns address and MAC address, and will let guys check the status of your DDNS client service.