[Question] Does this iptables rule cause unnecessary routing?

[statick@programming.dev]

I'm routing game traffic on my VPS via wireguard to a home server that has games hosted via docker.

Setup is...

VPS/Wireguard -> Internet -> Wireguard/Dockerized Games Server

Now, my current config WORKS... however I'm curious if there is some unnecessary routing going on.

VPS iptable rules (omitted PostDown)

PostUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --match multiport --dports 61000:61100 -j DNAT --to-destination 10.0.0.3
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Game Server (omitted PostDown)

Here are the iptable rules on the game server and the --to-destination part is what I'm curious about...

PostUp = iptables -t nat -A PREROUTING -p tcp --dport 61000:61100 -d 10.0.0.3 -j DNAT --to-destination 192.168.1.14
PostUp = iptables -t nat -A POSTROUTING -j MASQUERADE

10.0.0.3 is the same machine as 192.168.1.14

The reason I'm setting the --to-destination ip to that is because the docker rules that are created in the Chain DOCKER section of the iptable rules are looking for the destination nam-games.localdomain which is my dns entry for the game server. I unfortunately don't think I can change these because I'm using a game server management panel called Pterodactyl that adds these. I also don't want to have to manually add rules to this every time I create a server.

Chain DOCKER (2 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere
DNAT       tcp  --  anywhere             nam-games.localdomain  tcp dpt:61000 to:172.18.0.2:61000
DNAT       udp  --  anywhere             nam-games.localdomain  udp dpt:61000 to:172.18.0.2:61000
DNAT       tcp  --  anywhere             nam-games.localdomain  tcp dpt:61001 to:172.18.0.3:61001
DNAT       udp  --  anywhere             nam-games.localdomain  udp dpt:61001 to:172.18.0.3:61001

Concerns

The setup I described above is the only config I have gotten to work, but I'm curious if it's hitting the server, then going the router, only to be routed back to the same machine again. If it is, is there a better way to set this up?

[shimitar@downonthestreet.eu]

Why still using iptables today?

Nftables has been the way to go for quite a while...

But I see you use docker, maybe that's why.

[max_p@lemmy.max-p.me]

but I'm curious if it's hitting the server, then going the router, only to be routed back to the same machine again.
10.0.0.3 is the same machine as 192.168.1.14

No, when you talk to yourself you talk to yourself it doesn't go out over the network. But you can always check using utilities like tracepath, traceroute and mtr. It'll show you the exact path taken.

Technically you could make the 172.18.0.0/16 subnet accessible directly to the VPS over WireGuard and skip the double DNAT on the game server's side but that's about it. The extra DNAT really won't matter at that scale though.

It's possible to do without any connection tracking or NAT, but at the expense of significantly more complicated routing for the containers. I would do that on a busy 10Gbit router or if somehow I really need to public IP of the connecting client to not get mangled. The biggest downside of your setup is, the game server will see every player as coming from 192.168.1.14 or 172.18.0.1. With the subnet routed over WireGuard it would appear to come from VPN IP of the VPS (guessing 10.0.0.2). It's possible to get the real IP forwarded but then the routing needs to be adjusted so that it doesn't go Client -> VPS -> VPN -> Game Server -> Home router -> Client.

[non_burglar@lemmy.world]

No v4/v6 dual stack mentioned here, nor any multi-action rules required, so nftables would be of no advantage here.

Unless you're just saying "new thing good, old thing bad" here, I'm not sure why bother mentioning nftables.

[statick@programming.dev]

The self hosted web interface tool I use called Pterodactyl Game Server Panel uses docker and iptables when it creates the game servers.

I'm just trying to add some additional routing since in using wireguard.

[statick@programming.dev]

Okay! Awesome, just wanted to make sure. And making the 172.18.0.0/16 subnet available is something I didn't think about (obviously) so that's good to know.

Thank you for you're detailed response!