[Question] Does this iptables rule cause unnecessary routing?
[Question] Does this iptables rule cause unnecessary routing?
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?
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,tracerouteandmtr. 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.
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 your detailed response!
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.
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 I'm using wireguard.
I tought so... Nothing bad with using iptables, just there is a better guy on the block, was wondering.
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.