Suggestions for Wireguard Guide Relating to Unbound

[NittanySeaLion]

Thank you for your contribution to the Pi-hole Community!

Please read the comments below to help us consider your Pull Request.

We are all volunteers and completing the process outlined will help us review your commits quicker.

Please make sure you

1. Base your code and PRs against the repositories developmental branch.
2. Sign Off all commits as we enforce the DCO for all contributions
3. Sign all your commits as they must have verified signatures
4. File a pull request for any change that requires changes to our documentation at our documentation repo

---

What does this PR aim to accomplish?:
This PR updates some language in the WireGuard section of the Guides. It provides a fix for using unbound with WireGuard. It also suggests ufw firewall rules for the wg0 and eth0 route when clients use the tunnel to access local devices (or routing all traffic). Other improvement place warnings in positions to warn before offending activities occur and provide more details in descriptions.

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code and I have tested my changes.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)
6. I have checked that another pull request for this purpose does not exist.
7. I have considered, and confirmed that this submission will be valuable to others.
8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
9. I give this submission freely, and claim no ownership to its content.

---

• I have read the above and my PR is ready for review. Check this box to confirm

[netlify]

✅ Deploy Preview for pihole-docs ready!

Name	Link
🔨 Latest commit	292f36b
🔍 Latest deploy log	https://app.netlify.com/sites/pihole-docs/deploys/65fcacebb60f6d0008da57cf
😎 Deploy Preview	https://deploy-preview-964--pihole-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[pralor-bot]

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/wireguard-and-unbound/66715/3

[pralor-bot]

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/err-too-many-redirects/66998/12

[DL6ER]

Others than that your change seems fine to me

[NittanySeaLion]

Are any other changes needed?

[yubiuser]

Something here looks incorrectly rendered, but the code seems right.

[rdwebdesign]

Line (186) starts with a space, breaking the code block rendering.

[Bucking-Horn]

This PR updates some language in the WireGuard section of the Guides. It provides a fix for using unbound with WireGuard.

it may be necessary to modify the unbound configuration file to allow unbound to respond to local DNS requests

I very much doubt that running Wireguard alongside Pi-hole would have an impact on unbound being used as Pi-hole's upstream.

For once, I am running that configuration myself, with our guide's interface: 127.0.0.1 and never had any issues, regardless whether a client would be connected directly or via Wireguard.

But more importantly, communication between Pi-hole and unbound is strictly local via 127.0.01, and as Pi-hole is unbound's only client, unbound can be expected to only ever receive DNS requests from 127.0.0.1.

If @NittanySeaLion's Wireguard installation would have changed that somehow, then I'd suspect its Wireguard PostUp/PostDown rules would incorrectly route DNS requests to unbound instead of Pi-hole.
If that would be the case, you should fix those rules rather than changing unbound's configuration.

That said:
I can think of a scenario where adopting unbound's listening behaviour could be required:
If you happen to run unbound in a Docker container (or perhaps some other virtualised environment), depending on that container's configuration, you may then need to allow access from the specific network that your Pi-hole would reside in and send its requests from.
Similar may apply if you'd just run Pi-hole in a container.
However, that would have no ties to Wireguard - it would be a general requirement, as unbound would else be isolated to listen to requests from 127.0.0.1, i.e. from within its container only , and neither Pi-hole nor any other process would thus be able to communicate with unbound.

Pi-hole's guide is strictly about installing unbound bare metal.
It doesn't cover running unbound in a container at all.

Thus, I'd expect the configuration of the chosen unbound Docker container to cater for appropriate listening behaviour, and its respective documentation to cover the details and caveats, but I am also currently unaware of an official unbound container, so unsure where this should be addressed then.

If we'd consider adding some recommendation to allow private networks with Pi-hole's guide, it should probably appear in a separate section for Docker/VM unbound installations, emphasising that this would apply strictly to those, but not to bare metals.

[Bucking-Horn]

As it turns out from the original forum discussion, the current PostUp nftables rules from Pi-hole's documentation are not considering network interfaces at all, and thus would incorrectly srcnat Pi-hole's requests from 127.0.0.1 to unbound on 127.0.0.1:5335, so unbound sees a request as originating from the Pi-hole host machine's private range IP.

This may go unnoticed, as long as you don't communicate with a peer that only accepts source IPs other than that private range, This would be the case for any traffic (not just DNS) received by any software, but most prominently affects unbound if you limit it to 127.0.0.1 as per our guide.

This should be fixed by changing https://docs.pi-hole.net/guides/vpn/wireguard/internal/:
The nftables rules from the docs have to only account for traffic originating from the wireguard interface going to the connectivity providing interface, e.g. eth0:

PostUp = nft add table ip wireguard; nft add chain ip wireguard wireguard_nat {type nat hook postrouting priority srcnat\; policy accept\;}; nft add rule ip wireguard wireguard_nat iifname %i oifname 'eth0' counter masquerade
PostUp = nft add table ip6 wireguard; nft add chain ip6 wireguard wireguard_nat {type nat hook postrouting priority srcnat\; policy accept\;}; nft add rule ip6 wireguard wireguard_nat iifname %i oifname 'eth0' counter masquerade

In addition, it would be required to remove the following line, as it would be no longer be true:

If you are using the nftables method to enable NAT, you do not need to specify the interface name for the PostUp and Post Down lines.