# Wireguard client routing help

**URL:** <https://dietpi.com/forum/t/wireguard-client-routing-help/13983>\
**Category:** General Discussion\
**Created:** [15 August 2022 17:05 UTC](https://dietpi.com/forum/t/wireguard-client-routing-help/13983 "2022-08-15T17:05:45Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![pihunt](https://dietpi.com/forum/user_avatar/dietpi.com/pihunt/32/2459_2.png) [@pihunt](https://dietpi.com/forum/u/pihunt)\
**Post date:** [15 August 2022 17:05 UTC](https://dietpi.com/forum/t/wireguard-client-routing-help/13983/1 "2022-08-15T17:05:45Z")

</div>

Hi All!

I have a media server (DietPi v8.7.1) that’s connected to a VPN service all the time. I’ve found out that my qBittorrent client is leaking my real IP through UDP. This qBittorrent client is in a docker container. What I’d like to do is to make sure all traffic is routed through the VPN tunnel, except the local network. The media server is accessible through SSH, so I have to be careful with the rules.

My config looks like this right now:

**/etc/wireguard/wg0-client.conf**

```auto
[Interface]
PrivateKey = xxxxxx
ListenPort = 51820
MTU = 1280
DNS = [192.168.1.5](https://192.168.1.5)
Address = [10.13.128.81/24](https://10.13.128.81/24)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = xxx
AllowedIPs = [0.0.0.0/0](https://0.0.0.0/0)
Endpoint = xxx [.xxx.xxx.xxx:1443](https://192.252.213.182:1443)
PersistentKeepalive = 25

```

**ip addr**

```auto
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet [127.0.0.1/8](https://127.0.0.1/8) scope host lo
        valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
     link/ether dc:a6:32:68:fa:72 brd ff:ff:ff:ff:ff:ff
     inet [192.168.1.5/24](https://192.168.1.5/24) brd [192.168.1.255](https://192.168.1.255) scope global eth0
         valid_lft forever preferred_lft forever

3: wg0-client: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
     link/none
     inet [10.13.128.81/24](https://10.13.128.81/24) scope global wg0-client
         valid_lft forever preferred_lft forever

4: br-87e2de2657b6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
      link/ether 02:42:ad:ad:ab:98 brd ff:ff:ff:ff:ff:ff
      inet [172.23.0.1/16](https://172.23.0.1/16) brd [172.23.255.255](https://172.23.255.255) scope global br-87e2de2657b6
         valid_lft forever preferred_lft forever

5: br-1058020cc9de: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
     link/ether 02:42:28:88:e5:83 brd ff:ff:ff:ff:ff:ff
     inet [172.19.0.1/16](https://172.19.0.1/16) brd [172.19.255.255](https://172.19.255.255) scope global br-1058020cc9de
        valid_lft forever preferred_lft forever

6: br-3be0c83b199f: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
      link/ether 02:42:aa:57:0d:b0 brd ff:ff:ff:ff:ff:ff
     inet [172.18.0.1/16](https://172.18.0.1/16) brd [172.18.255.255](https://172.18.255.255) scope global br-3be0c83b199f
         valid_lft forever preferred_lft forever

7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
     link/ether 02:42:6e:ac:92:e9 brd ff:ff:ff:ff:ff:ff
     inet [172.17.0.1/16](https://172.17.0.1/16) brd [172.17.255.255](https://172.17.255.255) scope global docker0
         valid_lft forever preferred_lft forever

17: vethe7c9ddd@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
     link/ether ee:03:30:5e:ce:c7 brd ff:ff:ff:ff:ff:ff link-netnsid 0

19: vethd2c23d1@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
     link/ether ca:ce:46:21:5b:db brd ff:ff:ff:ff:ff:ff link-netnsid 1

21: veth3bf27a5@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
     link/ether 12:ff:be:31:e1:d5 brd ff:ff:ff:ff:ff:ff link-netnsid 2

23: veth749458c@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
     link/ether 4e:93:13:23:e3:5a brd ff:ff:ff:ff:ff:ff link-netnsid 3

```

**ip route show**

```auto
default via [192.168.1.1](https://192.168.1.1) dev eth0 onlink
[10.13.128.0/24](https://10.13.128.0/24) dev wg0-client proto kernel scope link src [10.13.128.81](https://10.13.128.81)
[172.17.0.0/16](https://172.17.0.0/16) dev docker0 proto kernel scope link src [172.17.0.1](https://172.17.0.1)
[172.18.0.0/16](https://172.18.0.0/16) dev br-3be0c83b199f proto kernel scope link src [172.18.0.1](https://172.18.0.1) linkdown
[172.19.0.0/16](https://172.19.0.0/16) dev br-1058020cc9de proto kernel scope link src [172.19.0.1](https://172.19.0.1) linkdown
[172.23.0.0/16](https://172.23.0.0/16) dev br-87e2de2657b6 proto kernel scope link src [172.23.0.1](https://172.23.0.1) linkdown
[192.168.1.0/24](https://192.168.1.0/24) dev eth0 proto kernel scope link src [192.168.1.5](https://192.168.1.5)

```

**route -n**

```auto
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
[0.0.0.0](https://0.0.0.0)[192.168.1.1](https://192.168.1.1)[0.0.0.0](https://0.0.0.0)UG 0 0 0 eth0
[10.13.128.0](https://10.13.128.0)[0.0.0.0](https://0.0.0.0)[255.255.255.0](https://255.255.255.0) U 0 0 0 wg0-client
[172.17.0.0](https://172.17.0.0)[0.0.0.0](https://0.0.0.0)[255.255.0.0](https://255.255.0.0)U 0 0 0 docker0
[172.18.0.0](https://172.18.0.0)[0.0.0.0](https://0.0.0.0)[255.255.0.0](https://255.255.0.0)U 0 0 0 br-3be0c83b199f
[172.19.0.0](https://172.19.0.0)[0.0.0.0](https://0.0.0.0)[255.255.0.0](https://255.255.0.0)U 0 0 0 br-1058020cc9de
[172.23.0.0](https://172.23.0.0)[0.0.0.0](https://0.0.0.0)[255.255.0.0](https://255.255.0.0)U 0 0 0 br-87e2de2657b6
[192.168.1.0](https://192.168.1.0)[0.0.0.0](https://0.0.0.0)[255.255.255.0](https://255.255.255.0) U 0 0 0 eth0

```

**192.168.1.1** is my router and **192.168.1.5** is my Raspberry Pi’s static IP address. **10.13.128.81** is the IP address assigned by my VPN provider.

**uname -a**

`Linux MediaServer 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux`

I’d like to know how should I configure the routing where the local network is still accessible, but all other traffic is routed through my wg0-client tunnel. Also, several ports needs to be forwarded through the VPN tunnel (torrent, plex, etc.) Please help me! Thank you!

---

<div class="post-metadata">

**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\
**Post date:** [16 August 2022 10:03 UTC](https://dietpi.com/forum/t/wireguard-client-routing-help/13983/2 "2022-08-16T10:03:02Z")

</div>

maybe @trendy could have a look.

---

<div class="post-metadata">

**Author:** ![trendy](https://dietpi.com/forum/user_avatar/dietpi.com/trendy/32/61_2.png) [@trendy](https://dietpi.com/forum/u/trendy)\
**Post date:** [18 August 2022 10:26 UTC](https://dietpi.com/forum/t/wireguard-client-routing-help/13983/3 "2022-08-18T10:26:03Z")

</div>

Why not implement the dietpi-killswitch?  
Currently firewall allows everything and default route is via router, so it’s like not having a VPN at all.

---

<div class="post-metadata">

**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\
**Post date:** [18 August 2022 10:40 UTC](https://dietpi.com/forum/t/wireguard-client-routing-help/13983/4 "2022-08-18T10:40:04Z")

</div>

@trendy if I’m not mistaken, our Killswitch is working for OpenVPN only. Isn’t it?

---

<div class="post-metadata">

**Author:** ![trendy](https://dietpi.com/forum/user_avatar/dietpi.com/trendy/32/61_2.png) [@trendy](https://dietpi.com/forum/u/trendy)\
**Post date:** [18 August 2022 11:10 UTC](https://dietpi.com/forum/t/wireguard-client-routing-help/13983/5 "2022-08-18T11:10:02Z")

</div>

If that is the case then we need to copy the rules from another topic, e.g

> [@Securing Pi using iptables (VPN gateway mode)](https://dietpi.com/forum/t/securing-pi-using-iptables-vpn-gateway-mode/4897/3):
>
> Native NordVPN app creates additional rules in the iptables firewall when connected or set to the KillSwitch mode. These rules bring mess in my own firewall configuration, and I couldn’t find a way either to disable or to adjust them. When connected or set to the KillSwitch mode the NordVPN app creates 3 additional rules in each section and puts them on top my rules: Input: -P INPUT DROP -A INPUT -s 104.140.53.106/32 -i eth0 -j ACCEPT -A INPUT -s 10.10.10.0/24 -i eth0 -j ACCEPT -A INPUT -i…

> [@Help remotely connecting using wireguard while NordVPN is running on PI](https://dietpi.com/forum/t/help-remotely-connecting-using-wireguard-while-nordvpn-is-running-on-pi/6293):
>
> PROBLEM My Pi is primarily used for Pihole and Home Automation (over Nordvpn). I need HELP remotely connecting to my network using Wireguard, while NordVPN is running on my Pi. I’ve tried a bunch of different routing rules, but I cant seem to get it. My wireguard client is unable to complete a handshake. Also I am ‘listening to all interfaces/all orgins’ on PIhole. If I chose one hop, i need to restart the pihole DNS after each reboot. I’ve seen a lot of threads on that as well, but I’m…

but first of all you need to enable default route over the wireguard tunnel.

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [18 August 2022 16:53 UTC](https://dietpi.com/forum/t/wireguard-client-routing-help/13983/6 "2022-08-18T16:53:32Z")

</div>

Also the iptables NAT rules look weird for a client. However, with `AllowedIPs = 0.0.0.0/0` WireGuard should setup ip rules to override the default route for everything but the WireGuard server itself. This differs from the 2 additional routes with OpenVPN sets up.

---

<div class="post-metadata">

**Author:** ![pihunt](https://dietpi.com/forum/user_avatar/dietpi.com/pihunt/32/2459_2.png) [@pihunt](https://dietpi.com/forum/u/pihunt)\
**Post date:** [19 August 2022 04:53 UTC](https://dietpi.com/forum/t/wireguard-client-routing-help/13983/7 "2022-08-19T04:53:23Z")

</div>

Thank you! Yes, the VPN works, I get a new external IP address after connecting to the VPN server. Wireguard is overriding the IP rules, however the default route is the router. That’s what should be changed to the wg0-client interface. But at the same time local ip addresses should not be routed through the VPN.

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [19 August 2022 05:43 UTC](https://dietpi.com/forum/t/wireguard-client-routing-help/13983/8 "2022-08-19T05:43:46Z")

</div>

Yes exactly, the WireGuard client rules only override the default route but not routes for local IP ranges. `ip rule show` should list them.

However you say qBittorrent is bypassing the VPN.

Is there a specific reason for the iptables NAT rules? Are those required for Docker, VLANs or so to work with the VPN?
