Replies: 3 comments 27 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I gave this a shot using a shadowsocks proxy. compose.ymlservices:
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 = cubicUnfortunately the connection is VERY spotty and not useful.
|
Beta Was this translation helpful? Give feedback.
-
|
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:
What works:
wg0 PostUp Configuration (Simplified): Additional Rules in Gluetun Container: Notes:
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. To make setup simpler: https://github.com/saturneric/wg-easy-gluetun Would love to hear your thoughts or suggestions for improvement! |
Beta Was this translation helpful? Give feedback.
-
Hi, could you show me docker-compose.yml for wg-easy + gluetun? everything starts for me, but when I change the postup and postdown and restart the interface, I have this error in wg-easy [request error] [unhandled] [GET] http://hide:51821/api/client cause: Error: Command failed: wg show wg0 dump }, docker-compose.yml version: "3" services: wg-easy: volumes: networks: |
Beta Was this translation helpful? Give feedback.
-
|
@pinqtape Hi! Thanks for reaching out. The error you’re seeing ( To make setup simpler and avoid these pitfalls, I’ve already packaged a one-click deployment that integrates wg-easy and gluetun with all necessary network, iptables, and interface configurations pre-wired. You can find it here: 👉 https://github.com/saturneric/wg-easy-gluetun It includes:
Feel free to clone it and start directly. If you run into anything unexpected, open an issue there and we can debug together. |
Beta Was this translation helpful? Give feedback.
-
You've created a whole repository for this OMG, I'll definitely test it, thank you very much. If you are wondering why I should direct traffic through gluetun to another server, the answer is simple: in Russia, wireguard traffic is blocked only to foreign servers, in the interior of Russia nothing is blocked from wired Internet providers, that is, i can make a simple tunnel user -> ru (wg-easy -> gluetun) -> eu (wireguard) -> internet |
Beta Was this translation helpful? Give feedback.
-
|
First of all, thank you for your excellent work! I really appreciate this project and use it daily. I noticed that there is an issue with portforward (I use NordVPN) which does not seem to work; the request fails with a timeout because the server is not responding to the NAT-PMP request. Here is the error log from Gluetun:
|
Beta Was this translation helpful? Give feedback.
-
You may create an issue here. And we can discuss about it later. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi! I would love some help from the community to get this working...
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!
Beta Was this translation helpful? Give feedback.
All reactions