Gluetun + Wg-easy container

[maodelg]

Hi! I would love some help from the community to get this working...

• I use a VPN Unlimited subscription with Gluetun, and it is working flawlessly, Gluetun container configuration is ok and tested.
• I also have a WG-Easy (Wireguard server container) configured, tested, and working.
• I want to have the wg-easy container to access the internet using the Gluetun network, so all my devices connected over my own VPN can benefit from the VPN Unlimited connection... this is to circumvent the hard limit of clients (5 total) that VPN Unlimited provides. In theory, I could connect any amount of devices using this method...
• After moving the open ports from the wg-easy container to the glutun one, and properly launching both, I just can't connect to the internet... No error, just can't browse the web or ping google from the GW-Easy clients...

Has anyone successfully recreated this use case? The idea is to have an unlimited amount of VPN clients using 1 slot of the paid VPN service by routing all of them over Gluetun using another custom VPN server container.

The WG-Easy server detects the client connection (see screenshot), but the client can't browse the internet... So the VPN connection between the CLIENT and WG-Easy server is being established trough the GLUETUN container, it's just like is not resolving DNS or something like that...

Thoughts?
Thanks!

[bnhf]

@maodelg

I think this is going to be difficult to do using a container like Wg-easy, as it has both cap_add and sysctls in the docker-compose. This means that the container has special capabilities to access the host that normal containers don't, and in this case means that Wg-easy would be going directly to the host at times when you want it to do everything through Gluetun.

What you are trying to do can likely be done, but I think you'll find that most VPN containers need at least a cap_add of NET_ADMIN to function, which will make it very tricky (probably impossible) to do using two containers.

I'd recommend doing this at the router level, using an x86 platform (industrial PCs with multiple ethernet ports work well), and running OpenWRT or pfSense as the RouterOS. I'm most familiar with OpenWRT, and with that you'd be able setup a WireGuard server, and VPN client (running OpenVPN or WireGuard), and have the Wireguard server use the VPN client for its outbound connection. The advantage of this approach, using a relatively powerful router device, is that it keeps the traffic off of your LAN if you have a large number of incoming Wireguard clients.

[nedix]

I gave this a shot using a shadowsocks proxy.

compose.yml

services:
  client:
    image: qmcgaw/gluetun:v3.39.0
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv6.conf.all.disable_ipv6=0
    environment:
      VPN_SERVICE_PROVIDER: ${WIREGUARD_CLIENT_SERVICE_PROVIDER}
      VPN_TYPE: wireguard
      WIREGUARD_MTU: 1296
      WIREGUARD_PRIVATE_KEY: ${WIREGUARD_CLIENT_PRIVATE_KEY}
      WIREGUARD_ADDRESSES: ${WIREGUARD_CLIENT_ADDRESSES}
      SERVER_COUNTRIES: ${WIREGUARD_CLIENT_COUNTRIES}
      SHADOWSOCKS: on
      SHADOWSOCKS_PASSWORD: "${SHADOWSOCKS_PASSWORD:-secret}"
      SHADOWSOCKS_CIPHER: aes-128-gcm
    restart: unless-stopped

  proxy:
    image: ghcr.io/shadowsocks/sslocal-rust:v1.20.4
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    entrypoint:
      - /bin/sh
      - -ec
      - >
        wget -qO- "https://gist.githubusercontent.com/nedix/27f291577b03ced31076b3e093b604d2/raw/e2ea27707ede65c7df044d7596c09609523cf741/local.conf" > /etc/sysctl.d/local.conf;
        setsid sslocal \
          -U \
          --protocol tun \
          --server-addr "client:8388" \
          --encrypt-method "aes-128-gcm" \
          --password "${SHADOWSOCKS_PASSWORD:-secret}" \
          --tun-interface-address "${NETWORK_PREFIX:-10.8.0}.0/32"
    ports:
      - 51821:51821/tcp
      - 51820:51820/udp
    depends_on:
      client:
        condition: service_healthy
    restart: unless-stopped

  server:
    image: ghcr.io/wg-easy/wg-easy:14
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv6.conf.all.disable_ipv6=0
    environment:
      WG_HOST: "${HOSTNAME:-host.docker.internal}"
      WG_DEFAULT_ADDRESS: "${NETWORK_PREFIX:-10.8.0}.x"
      WG_MTU: 1296
      WG_POST_UP: >
        ip route add default dev tun0 table 123;
        ip rule add from "${NETWORK_PREFIX:-10.8.0}.0/24" table 123;
    network_mode: service:proxy
    volumes:
      - /config
    restart: unless-stopped

/etc/sysctl.d/local.conf

# Source: https://github.com/shadowsocks/shadowsocks/wiki/Optimizing-Shadowsocks

# max open files
fs.file-max = 51200
# max read buffer
net.core.rmem_max = 67108864
# max write buffer
net.core.wmem_max = 67108864
# default read buffer
net.core.rmem_default = 65536
# default write buffer
net.core.wmem_default = 65536
# max processor input queue
net.core.netdev_max_backlog = 4096
# max backlog
net.core.somaxconn = 4096

# resist SYN flood attacks
net.ipv4.tcp_syncookies = 1
# reuse timewait sockets when safe
net.ipv4.tcp_tw_reuse = 1
# turn off fast timewait sockets recycling
net.ipv4.tcp_tw_recycle = 0
# short FIN timeout
net.ipv4.tcp_fin_timeout = 30
# short keepalive time
net.ipv4.tcp_keepalive_time = 1200
# outbound port range
net.ipv4.ip_local_port_range = 10000 65000
# max SYN backlog
net.ipv4.tcp_max_syn_backlog = 4096
# max timewait sockets held by system simultaneously
net.ipv4.tcp_max_tw_buckets = 5000
# turn on TCP Fast Open on both client and server side
net.ipv4.tcp_fastopen = 3
# TCP receive buffer
net.ipv4.tcp_rmem = 4096 87380 67108864
# TCP write buffer
net.ipv4.tcp_wmem = 4096 65536 67108864
# turn on path MTU discovery
net.ipv4.tcp_mtu_probing = 1

# for high-latency network
# net.ipv4.tcp_congestion_control = hybla

# for low-latency network, use cubic instead
net.ipv4.tcp_congestion_control = cubic

Unfortunately the connection is VERY spotty and not useful.

[saturneric]

Hi everyone!

I’ve successfully implemented this setup, and it’s working really well with no noticeable performance issues. Here’s a cleaned-up and more straightforward explanation:

Summary:

The setup allows wg-easy (WireGuard) traffic (10.8.0.0/24) to be routed through Gluetun (172.32.0.4). The network bridge VPN uses the subnet 172.32.0.0/24, where:

• 172.32.0.4 = Gluetun (VPN Container)
• 172.32.0.8 = wg-easy (WireGuard Server Container)

What works:

• Traffic from wg-easy clients (10.8.0.0/24) is routed through Gluetun to reach the internet.
• This setup works regardless of whether Gluetun uses OpenVPN or WireGuard as the protocol.
• The method allows for unlimited clients to connect via wg-easy using a single VPN slot.

wg0 PostUp Configuration (Simplified):

iptables -P FORWARD DROP;
iptables -A FORWARD -i wg0 -j ACCEPT;
iptables -A FORWARD -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT;
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE;
ip rule add from 10.8.0.0/24 table 200;
ip route add default via 172.32.0.4 dev $VPN table 200;

Additional Rules in Gluetun Container:

iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -t nat -A PREROUTING -i tun0 -p tcp --dport <Remote_Port> -j DNAT --to-destination 172.32.0.8
iptables -t nat -A PREROUTING -i tun0 -p udp --dport <Remote_Port> -j DNAT --to-destination 172.32.0.8

Notes:

• If you want devices within 10.8.0.0/24 to be able to communicate with each other, you will need to configure additional routing tables or firewall rules.
• <Remote_Port> refers to your VPN’s remote port forwarding. This can be customized according to your needs.

Results:

This approach allows all clients connected to wg-easy to access the internet through the VPN connection provided by Gluetun. This effectively bypasses any client limits set by the VPN provider.

You can also check out related articles I wrote: https://blog.bktus.com/en/archives/2918/

Would love to hear your thoughts or suggestions for improvement!

[tomorrow-nf]

When connected to WG:
Desktop (ethernet): Sites resolve, DNS leak tests show my IP is from mullvad and DNS ip/hostname match my public DNS record. That seems to be working fine - I don't think this is an issue on the pihole/unbound side, but I may be wrong.
Android (wifi): Exact same results as above. Testing different sites to ensure I'm not just hitting cached results.
Android (data): Cached results load, but nothing new. nslookups for my domain and google via 172.32.0.16 and 8.8.8.8 all return the expected results
Steam deck connected to mobile tether for the hell of it: Same as the above, as expected

I think the issue is that each device’s WireGuard client has its own DNS settings, and some of them may not have been updated or unified. Please check the DNS configuration for the Tunnel on your phone’s WG client. Then make sure that the DNS server’s IP address is reachable through the WireGuard tunnel. In other words, when you switch to cellular data, your phone still needs to be able to access that DNS server (for example, an address in 192.168.0.0/16 or whatever subnet your Pi-hole/Unbound is on) over the VPN.

I was thinking something like that, but for consistency's sake I've been using the same .conf across all devices for testing (never having more than one active at a time of course). Always an identical configuration

[saturneric]

I was thinking something like that, but for consistency's sake I've been using the same .conf across all devices for testing (never having more than one active at a time of course). Always an identical configuration

I didn’t notice you already ran nslookup on your phone. That means your phone or Deck isn’t actually using the DNS provided by WireGuard. To rule out an ISP issue, try connecting your laptop/desktop to your phone’s hotspot and see if WG behaves correctly. Most likely Android on cellular still isn’t using the DNS you set in WireGuard. Maybe disable Private DNS and make sure DNS traffic is routed through the tunnel—this usually resolves the problem.

Also, are you using DoT or any other privacy-enhanced DNS settings on your phone? To ensure maximum compatibility, does your DNS server allow queries over plain UDP port 53, or does it force DNS-over-TLS/HTTPS only?

You can check the following as well(some of the possible reasons):

• IPv6 leak: Does your WireGuard client include ::/0 in AllowedIPs so that IPv6 DNS requests go through the tunnel, or is it only routing 0.0.0.0/0?
• Pi-hole ACLs: Is Pi-hole configured to listen on the WG subnet for UDP port 53, or is it restricted to just your LAN range?
• Path MTU: Could MTU be too large, so that DNSSEC responses are dropped/fragments never reassembled?

[tomorrow-nf]

Also, are you using DoT or any other privacy-enhanced DNS settings on your phone? To ensure maximum compatibility, does your DNS server allow queries over plain UDP port 53, or does it force DNS-over-TLS/HTTPS only?

You can check the following as well(some of the possible reasons):

* IPv6 leak: Does your WireGuard client include ::/0 in AllowedIPs so that IPv6 DNS requests go through the tunnel, or is it only routing 0.0.0.0/0?

* Pi-hole ACLs: Is Pi-hole configured to listen on the WG subnet for UDP port 53, or is it restricted to just your LAN range?

* Path MTU: Could MTU be too large, so that DNSSEC responses are dropped/fragments never reassembled?

Definitely some homework to look into, appreciate the help with this. Just tested on my wife's phone, and it seems like this is something specifically with my own, and not likely the WG setup entirely. That should give me something to go off of

[tomorrow-nf]

Welp, after a day of fighting, a brief venture into headscale (basically all set up and working perfectly until I realized it only really works as an exposed service ideally on a VPS), I've tried reverting back to my wg-easy v14 setup, and this time it just works - not sure what I broke last time. The only changes I had to make from the initial setup were specifying DOT=off and DNS_PLAINTEXT_ADDRESS in the gluetun container (honestly not really sure how this was working for me in the past without those).

My sinking suspicion is this has something to do with v15's ipv6 handling. v14 and headscale worked basically out of the box on all devices with ipv6 disabled, but the disable flag doesn't work in v15 (and actually causes startup to fail), so I wonder if enforcing ipv6 is somehow messing with DNS resolution - maybe GrapheneOS on my phone does something funky there.

I'll let v15 mature a bit and come back down the road I think. For now, no need to fix what isn't broken.

[thiswillbeyourgithub]

@saturneric what a coincidence! I have been trying to do that wg-easy+glutun setup since yesterday and was banging my head against the wall. Your solution (from your latest blog post) worked perfectly on the first try. Thank you very much.

As I'm sure the docker compose will evolve as criticism is made, I do believe you should put an updated docker compose file in a specific repo.

Also, glutun allows setting the interface name via VPN_INTERFACE=gluevpn0, but then the rest of the configuration must be updated to replace tun0 by gluevpn0. I believe it might be better to do that as it would both increase legibility and help folks with advanced setup that maybe already have a tun0 interface for some reason.

Anyway thank you very much and I've just subscribed to your blog :)