I'm currently trying to route traffic through my VPS to my server, because my server doesn't have public IP. I'm using WireGuard to create tunnel between the server and VPS and iptables to route the traffic. The scenario I'm currently testing consists of the WireGuard tunnel running in Docker container and the application I'm trying to reach in other Docker container. The containers are on the same network.
I have run tcpdump inside both containers and the logs make me think there is something wrong with the MASQUERADE rule or Docker is somehow blocking traffic from the application container to the WireGuard container, but the fact that I can ping from WireGuard container to the application container makes me think that it's the first option. I was unfortunately unable to enable iptables, ip or ping usage inside the application container (in the WireGuard container it worked out of the box), therefore debugging is much more difficult.
What could be the possible root cause and how can I fix it?
Also I think it is pretty obvious that this isn't my area of expertise, therefore I would be glad for any suggestions. The ultimate goal is just to route incoming traffic from client through the VPS to the application and back through the VPS without altering any other aspect of the networking (applications can access the internet directly).
The network layout:
WireGuard VPS - IP: 10.13.13.1, NIT: wg0 WireGuard server - IP: 10.13.13.2, NIT: wg0 WireGuard server on app network - IP: 172.22.0.3, NIT: eth1 Application - IP: 172.22.0.2, NIT: eth0 WireGuard config on the VPS:
[Interface] Address = 10.13.13.1/32 ListenPort = 51820 PrivateKey = <key> PostUp = iptables -t nat -A PREROUTING -p tcp --dport 8096 -i eth0 -j DNAT --to-destination 10.13.13.2 PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostUp = iptables -A FORWARD -i eth0 -o %i -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT PostUp = iptables -A FORWARD -i %i -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT PostUp = iptables -A FORWARD -i %i -o %i -j ACCEPT PostDown = iptables -t nat -D PREROUTING -p tcp --dport 8096 -i eth0 -j DNAT --to-destination 10.13.13.2 PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i eth0 -o %i -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT PostDown = iptables -D FORWARD -i %i -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT PostDown = iptables -D FORWARD -i %i -o %i -j ACCEPT [Peer] # Server PublicKey = <key> PresharedKey = <key> AllowedIPs = 10.13.13.2/32 WireGuard config on the server:
[Interface] Address = 10.13.13.2/32 PrivateKey = <key> DNS = 10.13.13.1 # DNAT incoming WireGuard traffic to containers PostUp = iptables -t nat -A PREROUTING -p tcp --dport 8096 -i wg0 -d 10.13.13.2 -j DNAT --to-destination 172.22.0.2 # Masquerade traffic so return goes through WireGuard PostUp = iptables -t nat -I POSTROUTING 1 -s 172.22.0.0/16 -j MASQUERADE # Allow forwarding between wg0 and Docker networks PostUp = iptables -A FORWARD -o eth1 -j ACCEPT PostUp = iptables -A FORWARD -i eth1 -j ACCEPT PostDown = iptables -D FORWARD -o eth1 -j ACCEPT PostDown = iptables -D FORWARD -i eth1 -j ACCEPT PostDown = iptables -t nat -D PREROUTING -p tcp --dport 8096 -i wg0 -d 10.13.13.2 -j DNAT --to-destination 172.22.0.2 PostDown = iptables -t nat -D POSTROUTING -s 172.22.0.0/16 -j MASQUERADE [Peer] PublicKey = <key> PresharedKey = <key> Endpoint = <endpoint>:51820 AllowedIPs = 0.0.0.0/0, ::/0 tcpdump on WireGuard's eth1:
12:35:53.048539 52:79:81:b5:09:d9 (oui Unknown) > ca:9a:cb:d5:ea:16 (oui Unknown), ethertype IPv4 (0x0800), length 66: <client-ip>.rct.o2.cz.9792 > 172.22.0.2.8096: Flags [S], seq 1533103962, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0 12:35:53.312881 52:79:81:b5:09:d9 (oui Unknown) > ca:9a:cb:d5:ea:16 (oui Unknown), ethertype IPv4 (0x0800), length 66: <client-ip>.rct.o2.cz.9841 > 172.22.0.2.8096: Flags [S], seq 2089774231, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0 tcpdump on applications's eth0:
12:35:53.048551 52:79:81:b5:09:d9 (oui Unknown) > ca:9a:cb:d5:ea:16 (oui Unknown), ethertype IPv4 (0x0800), length 66: <client-ip>.rct.o2.cz.9792 > 14bed5065cf0.8096: Flags [S], seq 1533103962, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0 12:35:53.048566 ca:9a:cb:d5:ea:16 (oui Unknown) > 56:89:39:40:9c:ba (oui Unknown), ethertype IPv4 (0x0800), length 66: 14bed5065cf0.8096 > <client-ip>.rct.o2.cz.9792: Flags [S.], seq 1532462512, ack 1533103963, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 12:35:53.312888 52:79:81:b5:09:d9 (oui Unknown) > ca:9a:cb:d5:ea:16 (oui Unknown), ethertype IPv4 (0x0800), length 66: <client-ip>.rct.o2.cz.9841 > 14bed5065cf0.8096: Flags [S], seq 2089774231, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0 12:35:53.312906 ca:9a:cb:d5:ea:16 (oui Unknown) > 56:89:39:40:9c:ba (oui Unknown), ethertype IPv4 (0x0800), length 66: 14bed5065cf0.8096 > <client-ip>.rct.o2.cz.9841: Flags [S.], seq 3758080721, ack 2089774232, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 
-s 172.22.0.0/16Shouldn't that be-d 172.22.0.2instead?