-
-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestions for Wireguard Guide Relating to Unbound #964
base: release/v6.0
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for pihole-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
ef6da5f
to
32b76ea
Compare
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 |
0155771
to
3924863
Compare
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Others than that your change seems fine to me
b33b3c3
to
9e3a28c
Compare
Are any other changes needed? |
|
||
But if you are using `unbound` to provide a recursive DNS server solution based on the Pi-hole's DNS guide, it may be necessary to modify the `unbound` configuration file to allow `unbound` to respond to local DNS requests. To do so, add a line `access-control: [local network subnet] allow` into `unbound`'s pi-hole.conf file and restarting unbound. For example, if your local network subnet hosting the Pi-hole device is 192.168.1.0/24: | ||
|
||
```bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line (186) starts with a space, breaking the code block rendering.
requested changes requested changes Update docs/guides/vpn/wireguard/client.md Co-authored-by: yubiuser <[email protected]> Signed-off-by: NittanySeaLion <[email protected]> Update docs/guides/vpn/wireguard/client.md Co-authored-by: yubiuser <[email protected]> Signed-off-by: NittanySeaLion <[email protected]> Update docs/guides/vpn/wireguard/internal.md Co-authored-by: yubiuser <[email protected]> Signed-off-by: NittanySeaLion <[email protected]> Update docs/guides/vpn/wireguard/internal.md Co-authored-by: yubiuser <[email protected]> Signed-off-by: NittanySeaLion <[email protected]> Update docs/guides/vpn/wireguard/server.md Co-authored-by: RD WebDesign <[email protected]> Signed-off-by: NittanySeaLion <[email protected]> Update client.md
423deb1
to
292f36b
Compare
I very much doubt that running Wireguard alongside Pi-hole would have an impact on For once, I am running that configuration myself, with our guide's But more importantly, communication between Pi-hole and 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 That said: Pi-hole's guide is strictly about installing Thus, I'd expect the configuration of the chosen 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 |
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/:
In addition, it would be required to remove the following line, as it would be no longer be true:
|
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
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:
git rebase
)