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.

  • CumBroth@discuss.tchncs.deEnglish
    1·
    4 months ago

    Gluetun likely doesn’t have the proper firewall rules in place to enable this sort of traffic routing, simply because it’s made for another use case (using the container’s network stack directly with network_mode: "service:gluetun").

    Try to first get this setup working with two vanilla Wireguard containers (instead of Wireguard + gluetun). If it does, you’ll know that your Wireguard “server” container is properly set up. Then replace the second container that’s acting as a VPN client with gluetun and run tcpdump again. You likely need to add a postrouting masquerade rule on the NAT table.

    Here’s my own working setup for reference.

    Wireguard “server” container:

    [Interface]
Address = <address>
ListenPort = 51820
PrivateKey = <privateKey>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = wg set wg0 fwmark 51820
PostUp = ip -4 route add 0.0.0.0/0 via 172.22.0.101 table 51820
PostUp = ip -4 rule add not fwmark 51820 table 51820
PostUp = ip -4 rule add table main suppress_prefixlength 0
PostUp = ip route add 192.168.16.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 eth0 -j MASQUERADE; ip route del 192.168.16.0/24 via 172.22.0.1

#peer configurations (clients) go here

    and the Wireguard VPN client that I route traffic through:

    # Based on my VPN provider's configuration + additional firewall rules to route traffic correctly
[Interface]
PrivateKey = <key>
Address = <address>
DNS = 192.168.16.81 # local Adguard
PostUp = iptables -t nat -A POSTROUTING -o wg+ -j MASQUERADE #Route traffic coming in from outside the container (host/other container)
PreDown = iptables -t nat -D POSTROUTING -o wg+ -j MASQUERADE

[Peer]
PublicKey = <key>
AllowedIPs = 0.0.0.0/0
Endpoint = <endpoint_IP>:51820

    Note the NAT MASQUERADE rule.