Does not traverse VPNs - Githubissues

MCMrARM / revolution-irc

A modern Android IRC client. #revolutionirc on Libera.chat

GNU General Public License v3.0

556 stars 62 forks source link

Does not traverse VPNs #253

Open ScriptTiger opened 4 years ago

ScriptTiger commented 4 years ago

Maybe someone else can verify this? It's a bit peculiar, but I can't get it to work with any VPN app. It works fine with proxy apps and apps that use the Android VPN service for things that are not VPN, like Tor VPN mode and firewall apps that use the VPN service to analyze and filter traffic but don't establish an actual VPN, but it always bypasses actual VPN apps, like OpenVPN, SSTP, etc. I have verified the VPNs work with various other apps, but just not this one for some reason.

MCMrARM commented 4 years ago

They should work I use the normal Java Socket API...

ScriptTiger commented 4 years ago

The only time I can stop it from leaking outside of a VPN is by using Android's VPN options for "Always-on VPN" and "Block connections without VPN", but it just ends up blocking it and it still does not want to traverse the VPN.

foxcpp commented 4 years ago

I have it working correctly with WireGuard VPN.

0x004a commented 4 years ago

I have it working correctly with WireGuard VPN.

@foxcpp What Android version ? Are you using an IRC bouncer ?

Revolution isn't working on Android 9. Only get messages if "force stop" the app, then on restart, receive the ZNC bouncer buffer. Then no more messages until "force stop" and restart the app again.

Think HoloIRC doesn't work either. So wonder if a lot of clients are using the same bad IRC library in their source.

foxcpp commented 4 years ago

I use Android 9 and a bouncer. I'm not sure exactly if I lose any messages - never noticed it being the case. I do not keep it always running though.

kurahaupo commented 3 years ago

A point worth considering is that (unlike most mobile apps) IRC uses a single continuous TCP stream, so connection changes are visible to the IRC client, and can't be hidden from the user.

This means that:

switching from WiFi to UMTS or vice versa;
changing WiFi AP;
any upsteam NAT change; and
connecting or disconnecting a VPN

will all disrupt an in-flight IRC session.

Moreover, some changes will result in "silent" failure, where both ends believe the connection is still "up" but no traffic can be exchanged. Timeouts in that case range from minutes to hours.

A VPN that isn't always-on, especially if it is triggered by a connection attempt, may disrupt the connection.

That might not apply if the connection can be brought up fast enough, which may explain why Wireguard is seemingly less affected than other VPN types.

MCMrARM commented 3 years ago

In addition Android on some versions of the platform actually keeps the mobile connection up for a while longer when switching to wifi as far as I am aware. (re to reconnects on connection changes)

kurahaupo commented 3 years ago

Buried in the developer options, one can elect to have the UMTS module remain turned on even while WiFi is connected, with the intention that "switching" is much faster (at some battery cost).

The UMTS connection is hidden from apps so they are not aware that the device is concurrently multi-homed. (I've tried to prevent session breakage by using iproute2 policy routing to ensure that an IRC session "sticks" to the mobile connection even when WiFi or USB data is up, but so far to no avail.)