What I'm looking to do is to route WAN traffic from my personal wireguard server through a gluetun container. So that I can connect a client my personal wireguard server and have my traffic still go through the gluetun VPN as follows:
client <--> wireguard container <--> gluetun container <--> WAN
I've managed to set both the wireguard and gluetun container up in a docker-compose file and made sure they both work independently (I can connect a client the the wireguard container and the gluetun container is successfully connecting to my paid VPN for WAN access). However, I cannot get route traffic from the wireguard container through the gluetun container.
Since I've managed to set both up independently I don't believe that there is an issue with the docker-compose file I used for setup. What I believe to be the issue is either the routing rules in my wireguard container, or the firewall rules on the gluetun container.
I tried following this linuxserver.io guide to get the following wg0.conf
template for my wireguard container:
[Interface]
Address = ${INTERFACE}.1
ListenPort = 51820
PrivateKey = $(cat /config/server/privatekey-server)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth+ -j MASQUERADE
# Adds fwmark 51820 to any packet traveling through interface wg0
PostUp = wg set wg0 fwmark 51820
# If a packet is not marked with fwmark 51820 (not coming through the wg connection) it will be routed to the table "51820".
# PostUp = ip -4 rule add not fwmark 51820 table 51820
# Creates a table ("51820") which routes all traffic through the gluetun container
PostUp = ip -4 route add 0.0.0.0/0 via 172.22.0.100
# If the traffic is destined for the subnet 192.168.1.0/24 (internal) send it through the default gateway.
PostUp = ip -4 route add 192.168.1.0/24 via 172.22.0.1
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth+ -j MASQUERADE
Along with the default firewall rules of the gluetun container
Chain INPUT (policy DROP 13 packets, 1062 bytes)
pkts bytes target prot opt in out source destination
15170 1115K ACCEPT 0 -- lo * 0.0.0.0/0 0.0.0.0/0
14403 12M ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
1 60 ACCEPT 0 -- eth0 * 0.0.0.0/0 172.22.0.0/24
Chain FORWARD (policy DROP 4880 packets, 396K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 360 packets, 25560 bytes)
pkts bytes target prot opt in out source destination
15170 1115K ACCEPT 0 -- * lo 0.0.0.0/0 0.0.0.0/0
12716 1320K ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT 0 -- * eth0 172.22.0.100 172.22.0.0/24
1 176 ACCEPT 17 -- * eth0 0.0.0.0/0 68.235.48.107 udp dpt:1637
1349 81068 ACCEPT 0 -- * tun0 0.0.0.0/0 0.0.0.0/0
When I run the wireguard container with this configuration I can successfully connect my client however I cannot connect to any website, or ping any IP.
During my debugging process I ran tcpdump
on the docker network both containers are in which showed me that my client is successfully sending packets to the wireguard container, but that no packets were sent from my wireguard container to the gluetun container. The closest I got to this was the following line:
17:27:38.871259 IP 10.13.13.1.domain > 10.13.13.2.41280: 42269 ServFail- 0/0/0 (28)
Which I believe is telling me that the wireguard server is trying, and failing, to send packets back to the client.
I also checked the firewall rules of the gluetun container and got the following results:
Chain INPUT (policy DROP 13 packets, 1062 bytes)
pkts bytes target prot opt in out source destination
18732 1376K ACCEPT 0 -- lo * 0.0.0.0/0 0.0.0.0/0
16056 12M ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
1 60 ACCEPT 0 -- eth0 * 0.0.0.0/0 172.22.0.0/24
Chain FORWARD (policy DROP 5386 packets, 458K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 360 packets, 25560 bytes)
pkts bytes target prot opt in out source destination
18732 1376K ACCEPT 0 -- * lo 0.0.0.0/0 0.0.0.0/0
14929 1527K ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT 0 -- * eth0 172.22.0.100 172.22.0.0/24
1 176 ACCEPT 17 -- * eth0 0.0.0.0/0 68.235.48.107 udp dpt:1637
1660 99728 ACCEPT 0 -- * tun0 0.0.0.0/0 0.0.0.0/0
Which shows that the firewall for the gluetun container is dropping all FORWARD traffic which (as I understand it) is the sort of traffic I'm trying to set up. What is odd is that I don't see any of those packets in the tcpdump of the docker network.
Has anyone successfully set this up or have any indication on what I should try next? At this point any ideas would be helpful, whether that be more debugging steps or recommendations for routing/firewall rules.
While there have been similar posts on this topic (Here and Here) the responses on both did not really help me.
Thank you for the reply! I've been busy the last couple of days so I just got around to looking back at this.
I tested out your advice and setup a wireguard container with the
MASQUERADE
NAT rule and it worked! However, when I tried it out again with the gluetun container. I'm still running into issues, but there is progress!With my setup before when I connect my client to the wireguard network I would get a "no network" error. Now when I try access the internet the connection times out. Still not ideal, but at least it's a different error than before!
With the
MASQUERADE
NAT rule in place, runningtcpdump
on the docker network shows that at least the two containers are talking to each other:but I still cannot get any internet access through the wireguard tunnel.
When exploring around the gluetun config I confirmed that the
MASQUERADE
rule was actually set:I think that the issue may be the default firewall rules of the gluetun block all traffic besides the VPN traffic via the main iptable:
I tried adding simple iptables rules such as
iptables -A FORWARD -i tun+ -j ACCEPT
(and the same witheth+
as the interface) but with no luck.If you think you can help I'll be down to try out other solutions, or if you need more information I can post it when I have time. If you don't think this will be an easy fix I can revert back to the wireguard-wireguard container setup since that worked. I tried to get this setup working so I could leverage the gluetun kill-switch/restart.
I think you already have a kill-switch (of sorts) in place with the two Wireguard container setup, since your clients lose internet access (except to the local network, since there's a separate route for that on the Wireguard "server" container") if any of the following happens:
wg-quick down wg0
inside the container)I can't be 100% sure, because I'm not a networking expert, but this seems like enough of a "kill-switch" to me. I'm not sure what you mean by leveraging the restart. One of the things that I found annoying about the Gluetun approach is that I would have to restart every container that depends on its network stack if Gluetun itself got restarted/updated.
But anyway, I went ahead and messed around on a VPS with the Wireguard+Gluetun approach and I got it working. I am using the latest versions of The Linuxserver.io Wireguard container and Gluetun at the time of writing. There are two things missing in the Gluetun firewall configuration you posted:
MASQUERADE
rule on the tunnel, meaning thetun0
interface.FORWARD
packets (filter table) by default. You'll have to change that chain rule toACCEPT
. Again, I'm not a networking expert, so I'm not sure whether or not this compromises the kill-switch in any way, at least in any way that's relevant to the desired setup/behavior. You could potentially set a more restrictive rule to only allow traffic coming in from<wireguard_container_IP>
, but I'll leave that up to you. You'll also need to figure out the best way to persist the rules through container restarts.First, here's the docker compose setup I used:
You already have your "server" container properly configured. Now for Gluetun: I exec into the container
docker exec -it gluetun sh
. Then I set the MASQUERADE rule on the tunnel:iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE
. And finally, I change the FORWARD chain policy in the filter table to ACCEPTiptables -t filter -P FORWARD ACCEPT
.Note on the last command: In my case I did
iptables-legacy
because all the rules were defined there already (iptables
gives you a warning if that's the case), but your container's version may vary. I saw different behavior on the testing container I spun up on the VPS compared to the one I have running on my homelab.Good luck, and let me know if you run into any issues!
EDIT: The rules look like this afterwards:
Output of
iptables-legacy -vL -t filter
:And the output of
iptables -vL -t nat
:I tried out your solution and it worked! I thought it was an iptables / firewall issue on the gluetun end but I didn't know which table the packets were going through.
There's also a way to set persistent iptable rules via gluetun, the docs are here
Thank you for your help! I'll clean up my configs, and post my working configs and setup process!