arch-rtorrentvpn
arch-rtorrentvpn copied to clipboard
binhex
Wireguard mode doesn't allow for remoting into docker pod
Since I've switched over from openvpn mode to wireguard mode on my docker container, I haven't been able to access rutorrent UI via external from my home. Only internally on the LAN can i access the UI through the servers LAN IP.
If I switch the container mode to openvpn, everything works again fine. The only change is using wireGuard. I even tried clearing all the iptables in the docker container while in wireguard mode and setting it all to ACCEPT. That did not fix it either.
This is my container config:
docker run -d \ --sysctl="net.ipv4.conf.all.src_valid_mark=1" \ --privileged=true \ -p 8118:8118 \ -p 9443:9443 \ --name=torrentvpn \ -v /docker/torrentvpn/data:/data \ -v /docker/torrentvpn/config:/config \ -v /mnt/pool:/pool \ -v /etc/localtime:/etc/localtime:ro \ -e VPN_ENABLED=yes \ -e VPN_USER= \ -e VPN_PASS= \ -e VPN_PROV=pia \ -e VPN_CLIENT=wireguard \ -e STRICT_PORT_FORWARD=yes \ -e ENABLE_PRIVOXY=yes \ -e ENABLE_AUTODL_IRSSI=yes \ -e ENABLE_RPC2=yes \ -e ENABLE_RPC2_AUTH=yes \ -e ENABLE_WEBUI_AUTH=yes \ -e RPC2_USER= \ -e RPC2_PASS= \ -e WEBUI_USER= \ -e WEBUI_PASS= \ -e LAN_NETWORK=192.168.0.0/24 \ -e NAME_SERVERS=209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1 \ -e DEBUG=false \ -e PHP_TZ=UTC \ -e UMASK=000 \ -e PUID=0 \ -e PGID=0 \ binhex/arch-rtorrentvpn
Have you tested reaching your container in wireguard mode from external DNS? Are you able to get it to work? Am I missing some form of configuration option? I don't get why it works when all I change is setting the NET_ADMIN back and removing priviledged mode and setting to openvpn.
I am using your latest stable build release.
Any assistance appreciated thanks!
Have you tested reaching your container in wireguard mode from external DNS? Are you able to get it to work?
im assuming thats a bad use of the word DNS, you mean can i access the rutorrent web ui over the internet whilst using wireguard right?, if that is the question then the answer is yes.
Is your run config the same as mine? I’m not sure why it won’t work. If I only change it from wireguard to OpenVPN, and remove the sysctl and change privileged to net_admin, rutorrent ui is then is accessible from the outside with my external dns. I’m not sure what else could be stopping it.
My setup is simple:
- External DNS for my subdomain is pointing to my home IP.
- Home router has configured port forwarding for port 9443 to route to the home server.
- Home server running ubuntu server 20.04 LTS.
- Docker version 19.03.13, build 4484c46d9d.
- Latest stable release of binhex/arch-rtorrentvpn.
- no iptables firewall or ubuntu firewall (UFW) enabled on server aside from whatever docker configures out of the box.
- Again, openVPN works fine for the configuration, only when wireguard enabled does the rutorrent web ui stop working via DNS and continues to work in the LAN.
On Thu, Nov 12, 2020 at 4:45 AM binhex [email protected] wrote:
Have you tested reaching your container in wireguard mode from external DNS? Are you able to get it to work?
im assuming thats a bad use of the word DNS, you mean can i access the rutorrent web ui over the internet whilst using wireguard right?, if that is the question then the answer is yes.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/binhex/arch-rtorrentvpn/issues/169#issuecomment-726055922, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUPLX2Z4LL7TR5MSWTD3VTSPPKGXANCNFSM4TS4TD2A .
I noticed tonight that PIA provides ovpn for their next gen servers. (This is why the whole issue arose, I was using old gen servers with openvpn configuration and they shut them down so I had to transition. But I was testing wireguard out prior to moving over to ensure it would work.) On next-gen ovpn server connection, the same issue occurs so it seems to not be limited to wireguard.
Are you using PIA?
Are you using PIA?
yep, openvpn and wireguard for next-gen network with PIA both work for external access to the application for me, are you sure your port forwarding is working on your router?.
yes it has to be working because when the old gen was up just the other day, it was working totally fine. Nothing on the router has changed. 9443 tcp is enabled to route to that server.
other applications on other ports are accessible externally still.
I was able to run
docker exec torrentvpn iptables -L -v -n
I tested turning off the container then turning on again to clear the iptables counts. I waited a few minutes without trying to reach port 9443. I saw the counter for incoming 9443 not count. Then I attempted to hit the container from accessing my public DNS on port 9443. I then saw the iptables counters grow for incoming. So the requests are making it to the container but the container is not responding back.
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 172.17.0.0/16 172.17.0.0/16
5234 1354K ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spt:1337
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9080
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:9080
6 360 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9443
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:9443
0 0 ACCEPT tcp -- eth0 * 192.168.0.0/24 0.0.0.0/0 tcp dpt:5000
1218 365K ACCEPT tcp -- eth0 * 192.168.0.0/24 172.17.0.0/16
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 0
564 276K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
5065 986K ACCEPT all -- wg0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 172.17.0.0/16 172.17.0.0/16
8993 1646K ACCEPT udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp dpt:1337
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:9080
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:9080
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:9443
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:9443
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 192.168.0.0/24 tcp spt:5000
1245 375K ACCEPT tcp -- * eth0 172.17.0.0/16 192.168.0.0/24
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
564 276K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
8955 1043K ACCEPT all -- * wg0 0.0.0.0/0 0.0.0.0/0
When I hit the container from my PC client, talking to the LAN IP of the server, the UI loads and the iptables chains show activity:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
433 115K ACCEPT all -- * * 172.17.0.0/16 172.17.0.0/16
9386 1876K ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spt:1337
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9080
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:9080
6 360 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9443
342 1138K ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:9443
0 0 ACCEPT tcp -- eth0 * 192.168.0.0/24 0.0.0.0/0 tcp dpt:5000
2351 729K ACCEPT tcp -- eth0 * 192.168.0.0/24 172.17.0.0/16
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 0
3908 2699K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
9211 1223K ACCEPT all -- wg0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
324 1139K ACCEPT all -- * * 172.17.0.0/16 172.17.0.0/16
16641 12M ACCEPT udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp dpt:1337
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:9080
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:9080
452 116K ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:9443
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:9443
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 192.168.0.0/24 tcp spt:5000
2497 1759K ACCEPT tcp -- * eth0 172.17.0.0/16 192.168.0.0/24
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
3908 2699K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
13568 11M ACCEPT all -- * wg0 0.0.0.0/0 0.0.0.0/0
note how the tcp dpt:9443 entry does not increment but the spt:9443 one does in the incoming chain.
Ok I don't know what happened but I tried using openvpn again, with the new gen servers, and it works fine. But i'd still like to understand how to make it work with wireguard config.
my openvpn config is:
docker run -d \
--cap-add=NET_ADMIN \
-p 8118:8118 \
-p 9443:9443 \
--name=torrentvpn \
-v /docker/torrentvpn/data:/data \
-v /docker/torrentvpn/config:/config \
-v /mnt/pool:/pool \
-v /etc/localtime:/etc/localtime:ro \
-e VPN_ENABLED=yes \
-e VPN_USER= \
-e VPN_PASS= \
-e VPN_PROV=pia \
-e VPN_CLIENT=openvpn \
-e STRICT_PORT_FORWARD=yes \
-e ENABLE_PRIVOXY=yes \
-e ENABLE_AUTODL_IRSSI=yes \
-e ENABLE_RPC2=yes \
-e ENABLE_RPC2_AUTH=yes \
-e ENABLE_WEBUI_AUTH=yes \
-e RPC2_USER= \
-e RPC2_PASS= \
-e WEBUI_USER= \
-e WEBUI_PASS= \
-e LAN_NETWORK=192.168.0.0/24 \
-e NAME_SERVERS=209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1 \
-e DEBUG=false \
-e PHP_TZ=UTC \
-e UMASK=000 \
-e PUID=0 \
-e PGID=0 \
binhex/arch-rtorrentvpn
docker exec torrentvpn iptables -L -v -n seedbox: Sat Nov 14 20:08:41 2020
Chain INPUT (policy DROP 101 packets, 13860 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 172.17.0.0/16 172.17.0.0/16
1099 691K ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spt:1198
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9080
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:9080
2476 930K ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9443
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:9443
0 0 ACCEPT tcp -- eth0 * 192.168.0.0/24 0.0.0.0/0 tcp dpt:5000
0 0 ACCEPT tcp -- eth0 * 192.168.0.0/24 172.17.0.0/16
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 0
13800 11M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1081 628K ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 172.17.0.0/16 172.17.0.0/16
1255 169K ACCEPT udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp dpt:1198
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:9080
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:9080
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:9443
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:9443
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 192.168.0.0/24 tcp spt:5000
0 0 ACCEPT tcp -- * eth0 172.17.0.0/16 192.168.0.0/24
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
13800 11M ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
3219 5038K ACCEPT all -- * tun0 0.0.0.0/0 0.0.0.0/0
ip route for openvpn configurations:
0.0.0.0/1 via 10.20.112.1 dev tun0
default via 172.17.0.1 dev eth0
10.20.112.0/24 dev tun0 proto kernel scope link src 10.20.112.29
128.0.0.0/1 via 10.20.112.1 dev tun0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
192.168.0.0/24 via 172.17.0.1 dev eth0
208.78.42.21 via 172.17.0.1 dev eth0
while for WireGuard the ip route is different:
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
192.168.0.0/24 via 172.17.0.1 dev eth0