Skip to content
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

Open
wants to merge 1 commit into
base: release/v6.0
Choose a base branch
from

Conversation

NittanySeaLion
Copy link

@NittanySeaLion NittanySeaLion commented Dec 3, 2023

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

Copy link

netlify bot commented Dec 3, 2023

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...

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
Copy link
Collaborator

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
Copy link
Collaborator

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

Copy link
Member

@DL6ER DL6ER left a 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

docs/guides/vpn/wireguard/client.md Outdated Show resolved Hide resolved
docs/guides/vpn/wireguard/client.md Show resolved Hide resolved
docs/guides/vpn/wireguard/server.md Outdated Show resolved Hide resolved
docs/guides/vpn/wireguard/server.md Outdated Show resolved Hide resolved
@NittanySeaLion
Copy link
Author

Are any other changes needed?

docs/guides/vpn/wireguard/client.md Outdated Show resolved Hide resolved
docs/guides/vpn/wireguard/client.md Outdated Show resolved Hide resolved
docs/guides/vpn/wireguard/client.md Outdated Show resolved Hide resolved
docs/guides/vpn/wireguard/internal.md Outdated Show resolved Hide resolved
docs/guides/vpn/wireguard/internal.md Outdated Show resolved Hide resolved

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Screenshot at 2024-03-09 12-58-30

Copy link
Member

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.

docs/guides/vpn/wireguard/server.md Outdated Show resolved Hide resolved
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
@Bucking-Horn
Copy link
Member

Bucking-Horn commented Sep 8, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants