Skip to content
Open
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions docs/guides/vpn/wireguard/internal.md
Original file line number Diff line number Diff line change
Expand Up @@ -84,6 +84,31 @@ The rules will then be cleared once the tunnel is down.

The important change is the extra `PostUp` and `PostDown` in the `[Interface]` section.
<!-- markdownlint-enable code-block-style -->

### `ufw`

If you are using UFW the above doesn't work and you will need to edit `/etc/ufw/before.rules`:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

UFW does not replace the NAT rules above - the nftables/iptables masquerade still runs; UFW just drops forwarded packets on top of it. Could we reword along the lines of:

UFW drops forwarded packets by default, so in addition to the NAT rules above you need to allow forwarding for the tunnel subnet by editing /etc/ufw/before.rules:

As-is, "the above doesn't work" reads as if UFW were an alternative to the nftables/iptables method rather than an extra step on top of it.


Insert this into the before.rules file but **before** the FIRST commit line:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

COMMIT is an uppercase literal directive in before.rules, but it is written as lowercase "commit" here while the IPv6 paragraph below writes "COMMIT". Let us use COMMIT in both places so it is consistent and matches what a reader actually greps for in the file.


```bash
# allow forwarding for trusted network
-A ufw-before-forward -s 10.10.10.0/24 -j ACCEPT
-A ufw-before-forward -d 10.10.10.0/24 -j ACCEPT
Comment on lines +96 to +97

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Blocking: this guide uses 10.100.0.0/24 for the WireGuard-internal IPv4 range everywhere else (10.100.0.1/24, 10.100.0.2/32, DNS = 10.100.0.1). 10.10.10.0/24 looks like a leftover from your own network - a reader copy-pasting it allows forwarding for a subnet they do not use, so forwarding still fails. Please change both lines to 10.100.0.0/24. The IPv6 rule below already reuses the guide's fd08:4711::/64, so only the IPv4 side needs the fix.

```

For IPv6 you need to do the same but at `/etc/ufw/before6.rules`:

Put the following near the bottom but **before** the first COMMIT line:

```bash
# allow forwarding for trusted network
-A ufw6-before-forward -s fd08:4711::/64 -j ACCEPT
-A ufw6-before-forward -d fd08:4711::/64 -j ACCEPT
```

Restart ufw for the changes to take effect: `systemctl restart ufw`

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

The rest of the guide prefixes root commands with sudo; sudo systemctl restart ufw (or the more idiomatic sudo ufw reload) would match.


## Allow clients to access other devices

In our standard configuration, we have configured the clients in such a way that they can only speak to the server. Add the network range of your local network in CIDR notation (e.g., `192.168.2.1 - 192.168.2.254` -> `192.168.2.0/24`) in the `[Peers]` section of all clients you want to have this feature:
Expand Down