Jump to content
Not connected, Your IP: 216.73.216.102
thecoachchen

Wireguard timing out, can't resolve DNS.

Recommended Posts

I'm running Ubuntu server 24.04. 

While using AirVPN suite, wireguard times out and can't resolve DNS. 

Therefore while using AirVPN Suite I can't connect to the internet. 

However, while using Eddie, I can use wireguard and I can connect to the internet. 

I want to switch to AirVPN suite because I want to have it guarantee connect during bootup. 

Wondering how to get it working on my machine. Enclosed is my bluetit.log.

bluetit.log

Share this post


Link to post

Hello!

This issue is still under investigation by our support team and the AirVPN Suite developers. Several findings have emerged from the logs and configuration review, and further analysis is needed to establish the cause. We will post the outcome of the investigation in this thread once it is available.

Kind regards
 

Share this post


Link to post

Hello!

@thecoachchen, thank you for your patience and for all the logs and tests you provided. As promised, here is the outcome. After investigating with the user, we could not confirm a single root cause for the WireGuard handshake failure on that system, and the investigation is now closed without a definitive fix. Some of the findings are useful for anyone with the same symptoms: Bluetit reports "Connected", then "WireGuard handshake failed to resume" and reconnects about every minute, with no Internet access and no name resolution.

1. Upgrade to AirVPN Suite 2.2.0, the current release, before anything else. The first line Bluetit writes to the log shows the version in use ("Starting Bluetit - AirVPN WireGuard/OpenVPN3 Service 2.2.0").
Version 2.2.0 also changes how the keys of a WireGuard configuration are read. In 2.1.0 and older a key beginning with "+" is read incorrectly, and the tunnel cannot complete a handshake with any server. If you must stay on an older version, create a new device in the Client Area and use it, so that it gets new keys.

2. Do not run two VPN clients at the same time (for example Eddie and Bluetit on the same computer), and never use the same device in two places at once (for example the Suite on two computers). Each device has its own WireGuard key and VPN address, so two simultaneous sessions with the same device conflict with each other. Exit Eddie completely before you start Bluetit, and create a separate device in the Client Area for each computer.

3. If names do not resolve even before the tunnel is up, check which DNS servers the system uses while no VPN is connected:

cat /etc/resolv.conf
resolvectl status
If they still list the VPN DNS, for example 10.128.0.1, a previous session did not end cleanly and did not restore the DNS settings. That address can be reached only inside the tunnel, so name resolution fails outside of it. The comment at the top of /etc/resolv.conf tells you which program wrote the file and where it saved the original. To restore the settings left by Bluetit, with the Bluetit service running, use:
goldcrest --recover-network

To restore the settings left by Eddie, start Eddie and exit it normally.

4. If, with "allowprivatenetwork yes" (the default), you can reach the devices in your own subnet but not other private subnets behind the same router (for example 192.168.1.0/24 works, 192.168.2.0/24 does not): Network Lock already allows 192.168.0.0/16, 10.0.0.0/8 and 172.16.0.0/12, but Bluetit sends traffic into the tunnel with a 128.0.0.0/1 route, which also covers 192.168.0.0/16. Only the subnet your computer is directly connected to keeps its own route. Add a more specific route to the other subnets through your LAN gateway, for example:
sudo ip route add 192.168.0.0/16 via 192.168.1.1
Replace 192.168.1.1 with your gateway. To make the route persistent on Ubuntu, add it to your Netplan configuration under the interface:

routes:
  - to: 192.168.0.0/16
    via: 192.168.1.1

If the problem persists with 2.2.0, please post here:
- distribution and version, and AirVPN Suite version
- your DNS setup: the output of "ls -l /etc/resolv.conf" and whether you use systemd-resolved, resolvconf or NetworkManager
- any other software that manages the firewall or the network on the same system (ufw, firewalld, Docker, Tailscale, another VPN)
- the Bluetit log of a whole failed attempt, from the start of the connection to the first "handshake failed" line. Bluetit writes to the system log with the tag "bluetit", for example:
sudo journalctl -t bluetit -b

- whether the Bluetit service terminated unexpectedly, as shown by:
systemctl status bluetit

Kind regards

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...