Wireguard VPN + Adguard + Unbound

Hello, I’m new to Raspberry PI and my current challenge is to connect my iPhone + iPad via VPN to my private network.
I’m not a unix expert - but with general understanding about IT.

Hardware:

  • Raspberry Pi 4B 8GB RAM
  • Cabled (no WiFi)

Homenetwork:

  • Fritzbox 3490
  • 192.168.65.0/24
  • Raspberry has an static IP within this range
  • Portforwarding in Fritzbox for Raspberry Wireguard Port (51820)

Installed software according to DietPi-Software (all the latest version)

  • 17 Git
  • 103 DietPi-RAMlog
  • 104 Dropbear
  • 117 PiVPN
  • 126 AdGuard Home
  • 182 Unbound
  • 200 DietPi-Dashboard (beta)

DietPi settings:

  • DietPi-DDNS (configured and on the page of the provider https://spdyn.de - SecurePoint I see every 10 minutes an update)
    → Might be that I need to change here something as the requested values are not 100% matching with my existing one - but with the current IP it’s “connected” to my dyn dns provider. Missing: current IP as a variable in provider URL (updated by IP change) - update.spdyn.de/nic/update?hostname=&myip=
    https://wiki.securepoint.de/SPDyn/Hostverwenden#OpenWRT
    I checked the ddns script - no “current ip” included. Maybe another way could work as well or I need to play around with some other options.

Plannes Use-case(s):

  • 01 AdBlock and secure DNS in private network for all connected devices (AdGuard Home + Unbound)
  • 02 VPN connection from outsite to the Raspberry to use the same functions

Use-case 01 is working as far as I can see
Use-case 02 is not working.

I tried within PiVPN:

  • Rasp.Pi local DNS
  • custom DNS with the IP of the Raspberry
  • public DNS (Cloudflare)
    My iPhone tells always handshare issues

→ recommendations are welcome which settings should be used.
I searched a lot and reviewd some pages - but without success.
I uninstalled PiVPN - so if you have some hints - I will try :wink:.

thanks a lot

lets do first thinks first and try to get your VPN working. Therefore put aside DNS tools AGH + Unbound for a moment.

  1. You are sure you forward correctly port 51820 (UDP, not TCP) to your DitePi device?
  2. DDNS resolution for your external IP address is working and pointing correctly to your actual external IP?
  3. Install WireGuard again (you could use our native implementation as well)
  4. Scan the QR code with the client app and connect the VPN
  5. On server side you should be able to see a establish connection by running wg command, indicated by an actual handshake

I assume it’s just a problem with wireguard, because inside your network you can reach the internet and ads are blocked, right?
To be sure you could test https://dnsleaktest.com/ to see if the used DNS server matches your public IP.
And if Adguard wouldn’t work you had already noticed :wink:

As far as I can remember it was quite easy to use PiVPN. It detected unbound and my PiHole, I think I just had to type in my DNS adress, then it gave me some QR code to config my clients.

For testing you could open port 22 and test if you can SSH into your device with your DDNS adress, to exclude issues with that.
And I don’t know if PiVPN detects Adguard automatically, but you can just check your wireguard config: cat /etc/wireguard/configs/.conf (it’s this path if you use PiVPN, if you installed wireguard natively, without PiVPN, this path may change)
Check for correct DNS adress (since it runs on the same machine it should be 10.6.0.1 (default config)) and your endpoint adress (some.ddnsdomain.net:51820)


edit: almost same post as above, didn’t saw it was already there, sry :slight_smile:

I thought and searched a little bit about your “DDNS” problem.
I don’t understand why they want to broadcast the IP in the URL, they just could use the IP from where the request came? The only usecase would be if the request is coming from another device / IP adress, but why would somebody want to do this?

Hower, there are some workarounds for your problem:
Since you have a fritzbox, you could handle the DDNS update via the FritzBox, they have instructions for this in their wiki:
https://wiki.securepoint.de/SPDyn/Hostverwenden#FRITZ.21Box

And I also found an update script on github, which you could run on your device via cron:
https://gist.github.com/harald-aigner/2282735f202cbb38f6893d4daec6f5fe

I also had a look into the dietpi-ddns script, and at the beginning it’s loading the dietpi-globals and in there is a variable $ip.
I have no idea if you can use this inside the update URL somehow, this is beyond my little knowledge about this stuff :slight_smile:
But the great admins/mods can answer this, for sure.

Thanks a lot for your help and support.
It’s now working.
The only differences to my last tries: I used now the Fritzbox for DYNDNS with spdyn.
I wanted to avoid using variables from someone within the URL - keep it simple to maintain → therefore I’m using now dyndns within the fritzbox.

DNS Server within the Wireguard Client Profile is my Raspi.

Wireguard Config for the Client:
[Interface]
PrivateKey =
Address = 10.6.0.2/24
DNS =

[Peer]
PublicKey =
PresharedKey =
Endpoint = :51820
AllowedIPs = 0.0.0.0/0, ::0/0

So it looks like the DYDNS (spdns) within DietPi was not working, maybe due to the fix IP within the URL - but the ping request to the was answering with my internet IP. intresting.
Maybe I had somewhere a typo.

is it working now using dyndns ??

Im still using spdns - but within FRITZ!box and not within Raspi.

And still no handhake? Or do you get a handshake now, but don’t receive anything?

And based on this I would use the VPN IP for the DNS and not the local IP of the device.
DNS = 10.6.0.1


Can you confirm somehow the DDNS domain is working? MAybe ping it or something?!

I saw my typo autocorrection within my post.
It NOW working - not „not“. I changed it in my post.
Sorry :wink:

ok will mark this as solved. Basically issue was with incorrect DDNS.

Yes I guess as well there was an issue with ddns.
Unclear if this was a typo or if these provider is just not working with the required url without adoption of further script.

I guess issue was the IP address variable, which is not set by dietpi-ddns