I set both to PostUp and reboot then try again?
Probably this as I didn’t always reboot between previous changes.
Yes, change them to PostUp, reboot and try.
Here’s updated conf:
PreDown = iptables -D INPUT -i eth0 -s 192.168.178.0/24 -j ACCEPT
PostUp = ip route add 192.168.178.0/24 dev eth0 table 51820
PostUp = ip route add 192.168.178.0/24 dev eth0 table 51821
PostUp = iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT
PostUp = iptables -A FORWARD -i eth0 -o wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostUp = iptables -A INPUT -i eth0 -s 192.168.178.0/24 -j ACCEPT
PostDown = ip route del 192.168.178.0/24 dev eth0 table 51820
PostDown = ip route del 192.168.178.0/24 dev eth0 table 51821
PostDown = iptables -D FORWARD -i eth0 -o eth0 -j ACCEPT
PostDown = iptables -D FORWARD -i eth0 -o wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE
Here’s updated commands output:
root@DietPi:~# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.59.244.2/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n
[#] ip route add 192.168.178.0/24 dev eth0 table 51820
[#] ip route add 192.168.178.0/24 dev eth0 table 51821
[#] iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT
[#] iptables -A FORWARD -i eth0 -o wg0 -j ACCEPT
[#] iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[#] iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
[#] iptables -A INPUT -i eth0 -s 192.168.178.0/24 -j ACCEPT
root@DietPi:~# wg-quick down wg0
[#] iptables -D INPUT -i eth0 -s 192.168.178.0/24 -j ACCEPT
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] iptables-restore -n
[#] ip route del 192.168.178.0/24 dev eth0 table 51820
[#] ip route del 192.168.178.0/24 dev eth0 table 51821
[#] iptables -D FORWARD -i eth0 -o eth0 -j ACCEPT
[#] iptables -D FORWARD -i eth0 -o wg0 -j ACCEPT
[#] iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[#] iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE
Everything is working. Does it seems good to you?
Yes, you can now delete these two from the conf and reboot.
You mean the PostUp right? It was PreUp then we changed to PostUp.
Yes, I copied it from an older post.
Yeah I tought that too but wanted to make sure given all the times we tried 
Here’s the updated commands output:
root@DietPi:~# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.59.244.2/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n
[#] ip route add 192.168.178.0/24 dev eth0 table 51820
[#] iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT
[#] iptables -A FORWARD -i eth0 -o wg0 -j ACCEPT
[#] iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[#] iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
[#] iptables -A INPUT -i eth0 -s 192.168.178.0/24 -j ACCEPT
root@DietPi:~# wg-quick down wg0
[#] iptables -D INPUT -i eth0 -s 192.168.178.0/24 -j ACCEPT
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] iptables-restore -n
[#] ip route del 192.168.178.0/24 dev eth0 table 51820
[#] iptables -D FORWARD -i eth0 -o eth0 -j ACCEPT
[#] iptables -D FORWARD -i eth0 -o wg0 -j ACCEPT
[#] iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[#] iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE
I think it’s good, do you? 
No errors, looks good, enjoy!
1 Like
Man thanks a lot! You don’t know how much I thank you 
I basically bought the RPi4 just for this and your help has been amazing!
Thanks again!
2 Likes
A bit late looping through notifications, nice that finally everything works as expected.
51820 is the default routing table used by WireGuard to force all (non-LAN) requests through the VPN, unless you define another one via Table option, which was initially an idea. It seems, as you used PreUp to define a manual 51820 route (which implicitly creates the table), WireGuard automatically switched to 51821 for its own routing table, and when you define a 51821 route as well, WireGuard uses 51822, just to not mess with existing routing tables.
One question to our gurus: What is the purpose of
iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT
?
I thought that IP forwarding is only ever done for forwarding requests between different interfaces, while requests within the same subnet are done moreless directly, without any router/switch/NAT routing/forwarding involved?
1 Like
Agreed! You guys gave me a lot of support, I cannot thank you enough for this
I think tables changing number was due to me not always rebooting between various tests. Last time we got it working, I rebooted before trying latest rules and everything was right and on the right table.
If I remember correctly, the Table option allows you to specify a custom table but you have to create one from scratch and I think it’s done “outside” WireGuard but again, I might be wrong.
No idea of this. Could probably be needed to forward request to the RPi4 back to the router?
Remember I’ve my RPi4 as gateway and dns on a couple of devices so when VPN is off the traffic goes to the RPi4 and then to the router.
Better waiting for the gurus anyway 
But the final solution was to move the commands from PreUp to PostUp, and finally remove them right? WireGuard automatically removes the routing table and rules it creates, but of course not the ones you manually create.
Right, AFAIK it creates the routing table then (and of course assigns the firewall marks to meta packets), but does not create the rules to assign this routing table to packets. I.e. these two steps should be missing:
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
But in this case, -i eth0 -o eth0 incoming and outgoing interfaces are the same, so it would match a request from one device within your LAN to another device within our LAN (any other would be -o wg0), in which case I am not sure whether the FORWARD table is applied at all, I mean no NAT is involved then. Not sure if such rule can technically match any packet.
Let’s wait for the gurus as you said
It is covering your requirement.
I was right then 
I still do not understand why the DietPi system would be even involved in routing if origin and target of the request (or gateway) are in the same network (both eth0). Does it not work when removing just one particular rule?
However, if it works, it works 
, I am just notoriously interested in understanding the background.
I’m sure @trendy would give us an explanation 
It is covering the case when the lan host uses dietpi as gateway, but the packet is forwarded not to vpn but to the ISP router.
1 Like
Ah, basically a double-NAT, once DietPi doing masquerading, and once again the ISP router? If the host is in the same LAN, of course I am wondering why it does not use the ISP router as gateway directly. But probably it is intended that the DietPi system does all routing decisions here, hence whether to pass packets through VPN or further to WAN directly. I am too lazy to read through all 99 comments again 
.