search

binhex / arch-delugevpn

Docker build script for Arch Linux base with Deluge, Privoxy and OpenVPN
GNU General Public License v3.0
696 stars 112 forks source link

Web UI no longer accessible outside local network when Wireguard is used #211

Closed charlie2alpha closed 3 years ago

charlie2alpha commented 4 years ago

As the subject says, can't access the WebUI outside my LAN when I use the container with PIA wireguard while I can access it if I switch to PIA openvpn. What could be causing this?

binhex commented 4 years ago

working with no issues here internally and externally with wireguard and openvpn, have you verified you have iptable_mangle loaded? read Q2 here:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

charlie2alpha commented 4 years ago

I've read the FAQ and yes, mangle is loaded. The same exact configuration works with openvpn as I stated, but just won't work with wireguard. The container runs on a Gentoo Linux machine, I've configured the kernel myself. What can I do to troubleshoot this? The symptom resembles the absence of a default gateway on eth0 but I'm not sure how to check this as the the usual commands "route" or "ip route show" show only a limited LAN route inside the container.

binhex commented 4 years ago

The symptom resembles the absence of a default gateway on eth0

if you can access the web ui inside your network with VPN_CLIENT set to wireguard then the gateway is correctly configured, otherwise it would never see a route out of the bridge network and thus the ui would be inaccessible.

you can double check its not a routing issue by exec'ing in and issuing:-

ip route s t all

which should show you all routes defined, you should see eth0 as the default gateway, like this default via 172.17.0.1 dev eth0

can you double check your LAN_NETWORK is defined correctly see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

charlie2alpha commented 4 years ago

I'm using the docker macvlan driver so the container has a normal LAN ip actually. Here's the result of the ip route command: [root@0a5663a227ab /]# ip route s t all default dev wg0 table 51820 scope link default via 192.168.1.254 dev eth0 table webui default via 192.168.1.254 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.12 local 10.35.159.96 dev wg0 table local proto kernel scope host src 10.35.159.96 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 broadcast 192.168.1.0 dev eth0 table local proto kernel scope link src 192.168.1.12 local 192.168.1.12 dev eth0 table local proto kernel scope host src 192.168.1.12 broadcast 192.168.1.255 dev eth0 table local proto kernel scope link src 192.168.1.12

192.168.1.12 is the container's LAN ip. The fact that I'm using it like this seems to play no part, I tried it with the normal docker networking and had the exact same problem, can't connect outside my LAN, not even when I VPN into my router from my phone, which places my phone on an 10.0.0.x network so essentially not in LAN subnet.

binhex commented 4 years ago

allocating an ip address to the container that is in the same range as LAN_NETWORK will cause issues, at least it does with a custom bridge, not sure about macvlan, i know you said you did try it with the 'normal docker networking' but you might want to try it again on the default bridge.