Update to 9.8 broke wireguard

After upgrading my Wireguard VPN stopped working… it connects but doesnt have any internet… Im using AdguardHome with unbound and PiVPN
This is the handshake info…

[handshake]
10-23 11:13:22.471 22254 22336 D WireGuard/GoBackend/indaRaspberry: peer(aWxi…sDx8) - Handshake did not complete after 5 seconds, retrying (try 2)
10-23 11:13:22.471 22254 22336 D WireGuard/GoBackend/indaRaspberry: peer(aWxi…sDx8) - Sending handshake initiation
10-23 11:13:27.662 22254 22276 D WireGuard/GoBackend/indaRaspberry: peer(aWxi…sDx8) - Handshake did not complete after 5 seconds, retrying (try 2)
10-23 11:13:27.662 22254 22276 D WireGuard/GoBackend/indaRaspberry: peer(aWxi…sDx8) - Sending handshake initiation
[/handshake]

This is my wg0.conf… I had no iptables before and it was working after searching i decided to add the postup/postdown to see if that fixed the issue but it didnt…

[Interface]
PrivateKey = [pkey]
Address = 10.25.161.1/24
MTU = 1420
ListenPort = 51820

PostUp = iptables -w -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -w -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -w -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -w -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = [pkey]
PresharedKey = [prkey]
AllowedIPs = 10.25.161.2/32

This is my iptables-saves -c

# Generated by iptables-save v1.8.9 (nf_tables) on Wed Oct 23 16:22:01 2024
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
[17234:11503990] -A FORWARD -j DOCKER-USER
[17234:11503990] -A FORWARD -j DOCKER-ISOLATION-STAGE-1
[0:0] -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A FORWARD -o docker0 -j DOCKER
[0:0] -A FORWARD -i docker0 ! -o docker0 -j ACCEPT
[0:0] -A FORWARD -i docker0 -o docker0 -j ACCEPT
[20211:13119764] -A FORWARD -o br-d02055d3da93 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[1350:70216] -A FORWARD -o br-d02055d3da93 -j DOCKER
[18032:8333293] -A FORWARD -i br-d02055d3da93 ! -o br-d02055d3da93 -j ACCEPT
[0:0] -A FORWARD -i br-d02055d3da93 -o br-d02055d3da93 -j ACCEPT
[0:0] -A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 9000 -j ACCEPT
[0:0] -A DOCKER -d 172.18.0.2/32 ! -i br-d02055d3da93 -o br-d02055d3da93 -p tcp -m tcp --dport 3001 -j ACCEPT
[0:0] -A DOCKER -d 172.18.0.5/32 ! -i br-d02055d3da93 -o br-d02055d3da93 -p tcp -m tcp --dport 80 -j ACCEPT
[0:0] -A DOCKER -d 172.18.0.5/32 ! -i br-d02055d3da93 -o br-d02055d3da93 -p tcp -m tcp --dport 81 -j ACCEPT
[513:26692] -A DOCKER -d 172.18.0.5/32 ! -i br-d02055d3da93 -o br-d02055d3da93 -p tcp -m tcp --dport 443 -j ACCEPT
[0:0] -A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
[7538:3742661] -A DOCKER-ISOLATION-STAGE-1 -i br-d02055d3da93 ! -o br-d02055d3da93 -j DOCKER-ISOLATION-STAGE-2
[17234:11503990] -A DOCKER-ISOLATION-STAGE-1 -j RETURN
[0:0] -A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
[0:0] -A DOCKER-ISOLATION-STAGE-2 -o br-d02055d3da93 -j DROP
[7538:3742661] -A DOCKER-ISOLATION-STAGE-2 -j RETURN
[39593:21523273] -A DOCKER-USER -j RETURN
COMMIT
# Completed on Wed Oct 23 16:22:01 2024
# Generated by iptables-save v1.8.9 (nf_tables) on Wed Oct 23 16:22:01 2024
*nat
:PREROUTING ACCEPT [59560:4405245]
:INPUT ACCEPT [59531:4403476]
:OUTPUT ACCEPT [109534:8212496]
:POSTROUTING ACCEPT [110884:8282712]
:DOCKER - [0:0]
[33513:2497081] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
[4:240] -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
[0:0] -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
[29:1769] -A POSTROUTING -s 172.18.0.0/16 ! -o br-d02055d3da93 -j MASQUERADE
[0:0] -A POSTROUTING -s 10.25.161.0/24 -o eth0 -m comment --comment wireguard-nat-rule -j MASQUERADE
[0:0] -A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 9000 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.18.0.2/32 -d 172.18.0.2/32 -p tcp -m tcp --dport 3001 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.18.0.5/32 -d 172.18.0.5/32 -p tcp -m tcp --dport 80 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.18.0.5/32 -d 172.18.0.5/32 -p tcp -m tcp --dport 81 -j MASQUERADE
[0:0] -A POSTROUTING -s 172.18.0.5/32 -d 172.18.0.5/32 -p tcp -m tcp --dport 443 -j MASQUERADE
[0:0] -A DOCKER -i docker0 -j RETURN
[342:20520] -A DOCKER -i br-d02055d3da93 -j RETURN
[0:0] -A DOCKER ! -i docker0 -p tcp -m tcp --dport 9002 -j DNAT --to-destination 172.17.0.2:9000
[0:0] -A DOCKER ! -i br-d02055d3da93 -p tcp -m tcp --dport 2283 -j DNAT --to-destination 172.18.0.2:3001
[0:0] -A DOCKER ! -i br-d02055d3da93 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.18.0.5:80
[0:0] -A DOCKER ! -i br-d02055d3da93 -p tcp -m tcp --dport 81 -j DNAT --to-destination 172.18.0.5:81
[513:26692] -A DOCKER ! -i br-d02055d3da93 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.18.0.5:443
COMMIT
# Completed on Wed Oct 23 16:22:01 2024

I don’t think this is directly related to DietPi. Probably your DDNS name is not updated correctly or port forwarding changed.

Unfortunately, you missed to fill the trouble shooting template and we don’t know what system you are using. At least on my production RPI4, WG is working without any issues.

Im using Rpi4 and I checked ddns and port but nothing have been touched…
I also checked with netstat and the port 51820 should be in LISTEN right?

it is there on the bottom as UDP. As said, usually these issues are not Wireguard server related. In most cases it’s an incorrect DDNS or port forwarding.

Theoretically you could test with a client inside your local network using local IP address instead of DDNS. This way you can check pure server functionality without port forwarding and DDNS

Blockquote
Theoretically you could test with a client inside your local network using local IP address instead of DDNS. This way you can check pure server functionality without port forwarding and DDNS

By this you mean changing the pivpnHOST and replacing the ddns and putting my local ip address right and test it that way?

Yes can be done directly inside the Wireguard client app as it is relevant on the client itself.

It works and gives me internet and everything is fine… but i checked ddns and have the ip correct and also checked the port in my router and everything is fine… you still think those two could be the problem right?

you could test with your external IP address directly to exclude DDNS. Best to test from outside your local network.

It worked using the ip directly… I tested it outside the network and everything works fine… im using a no-ip ddns what could be the problem? It was working fine before and i checked the ip and its good… could it be adguardhome blocking no-ip dns?

I doubt AGH has an influence, because outside your local network you don’t use AGH to perform the initial connection

I have changed all my DietPi installs to use OpenSSH (server and client) instead of DropBear. When I had trouble using rsync cron jobs via SSH ( ssh-keygen) DropBear gave me all sorts of headaches because DropBear’s install does not follow the same file structure as OpenSSH (the standard). HomeLab with Pis https://metaprax.neocities.org/

For WireGuard you have to follow the install instructions to the letter. Trying to hand edit the wg0.conf file does not work. I am not sure what the issue is - maybe the wrong number of spaces or line returns in a hand edited wg0.conf.

I changed nothing I added the iptables because i saw some older post with it and tried but i have an original backup file. everything stayed the same… but right now it works with my ip directly into the host of the client but not with ddns.

@metaprax issue has nothing to do with SSH server or Wireguard server configuration. Your comments are more confusing as they don’t have a relationship to the issue itself.

It’s related to DDNS.

This topic was automatically closed 178 days after the last reply. New replies are no longer allowed.