WireGuard client | Add split tunnel functionality

rainfallsevensamurai commented 3 years ago

Required Information

DietPi version | 7.1.2
Distro version | Buster
Kernel version | 4.9.241-arm64 #1 SMP PREEMPT Thu Feb 25 17:57:15 CET 2021 aarch64 GNU/Linux
SBC model | Odroid C4/HC4 (aarch64)
Power supply used | 12V 2A
SDcard used | 32GB eMMC Module

Additional Information (if applicable)

Software title | Deluge-web and qbittorrent
Was the software title installed freshly or updated/migrated? Freshly installed using dietpi-software
Can this issue be replicated on a fresh installation of DietPi? It is a fresh installation

Steps to reproduce

Use dietpi-software to install deluge or qbittorent
Try to open the webpage (port 8112 or 1340) on a laptop

Expected behaviour

The webpage should open

Actual behaviour

Timeout error

Extra details

Pihole is running as well and their page ip/admin is working fine, so the problem seems related to the port number?

MichaIng commented 3 years ago

AllowedIPs = 0.0.0.0/0,::0/0,192.168.1.0/24

In this case, the added IP should have no effect, and what I stated above stays true: The first two entries mean that every request shall be tunnelled, so the LAN IP range is first of all included, as long as not overwritten by other defined routes or rules. But probably it indirectly has an effect. How does the WireGuard routing table actually look like?

ip r l table 51820

You are not connected to Mullvad. Your IP address is [my local IP]

You mean your regular public IP, not your "local=LAN" IP, don't you?

That it works with the SOCKS5 proxy does not necessarily mean the all your traffic (aside of LAN) is tunnelled, as that proxy uses explicitly the VPN servers internal IP. So it is possible that only requests to 10.64.* are tunnelled, while everything else is bypassing the VPN. A route for the subnet of the interface itself is default, but what we want is routing everything through the VPN, excluding only the LAN range. Would be awesome if WireGuard had an UnallowedIPs setting to exclude subnets within the AllowedIPs, then all the manual route/rule hack wouldn't be required at all 😄.

rainfallsevensamurai commented 3 years ago

Yeah, I have no idea what I'm doing :)

ip r l table 51820 returns nothing.

Indeed my public IP.

MichaIng commented 3 years ago

Interesting, but ip rule shows the rule ending with lookup 51820? I'm confused 😄. Although it would fit to the case that currently nothing is tunnelled by default, but only when the VPN is actively used as proxy. Actually, in many cases with BitTorrent, this is quite the wanted case: Only the BitTorrent software uses the VPN via SOCKS5 socket, while everything else bypasses it, including requests from/to LAN.

rainfallsevensamurai commented 3 years ago

I'm confused as well and I think it's not really working. For now, it appears like the tunnel is not active at all. But, the scenario you speak of, is exactly what I'm looking for.

Joulinar commented 2 years ago

I guess a duplicate request, similar like https://github.com/MichaIng/DietPi/issues/2758

MichaIng commented 2 years ago

You are right. Let's focus on WireGuard here and have the other one for DietPi-VPN. While there are overlaps, the implementation differs.

MichaIng / DietPi