I recall seeing a thread here about VPN's blocking new inbound traffic to devices starting with Android 25, but can't find that thread.
I ask because ever since Android 15 came out, I can't seed torrents once download is complete. I tried several providers, but the result is the same. Such result usually means that no new inbound traffic is allowed. That is kind of good, except I have no idea how to re-allow inbound traffic through VPN tunnel...
H7oUt I can't seed torrents once download is complete
The issue may be not the Android itself, but the fact that more and more VPN providers stop port forwarding. You used to have this ability on Mullvad, but they don't have it anymore. It's kinda available with Proton, but only with apps, or while jumping some hoops for CLI configuration.
May be of interest:
https://mullvad.net/en/blog/removing-the-support-for-forwarded-ports
https://protonvpn.com/support/port-forwarding/
P.S. I think that Development tag is not relevant here.
@thmf is right. Port forwarding so that other peers can connect to you is not permitted by basically any VPN anymore, because I caused huge amounts of legal liability for VPN providers, as they actually did have identifying information to hand over to law enforcement, which account the specific forwarded port is tied to. And because people exploited that functionality to set up websites with illegal content on, effectively making the VPN the hosting provider for those websites. But BitTorrent and other peer-to-peer technologies should still be able to accept incoming connections by using UDP hole-punching technologies. That technology exploits the stateless nature of UDP to fool the VPN into thinking it is an outgoing connection instead of an incoming one, and thus the VPN will accept the incoming data as responses. I never used any peer-to-peer technology on my phone, but it should work, as it definitely does with major VPN providers on my computer. So although seeding ability will be heavily limited when using a VPN, you should still receive some incoming connections, and either way you should be able to seed to nodes that themselves can accept incoming connections.
Dumb question maybe, but are you certain there even are nodes in the swarm to seed to?
I see, but I used to seed after download is complete on Android 14, but not Android 15. There was definitely a thread about Android 15 VPN implementation changes on these forums. I just cannot find it...
I found it, but it was not on these forums - https://github.com/celzero/rethink-app/issues/224 .
H7oUt I don't remember seeing any such thread or talk about any such changes. I also just now did search the Android 15 official change log, and they don't mention anything in relation to VPN. The only thing that has changed with the VPN implementation in GrapheneOS recently, is that about half a year ago, GrapheneOS developers fixed all the VPN leaks I had reported to them. But nothing of that should affect incoming connections and especially not UDP hole-punching.
Are you certain there are nodes in the swarm to seed to?
I imagine that if UDP hole-punching broke, we would have seen more complaints, as many apps that offer voice calls and video calls would break when used over a VPN in that case, as voice calls and video calls are almost always implemented using peer-to-peer technology too, and relies very heavily on UDP hole-punching.
H7oUt I found it, but it was not on these forums - https://github.com/celzero/rethink-app/issues/224 .
Oh.. I didn't know that, that incoming traffic from non-VPN interfaces didn't use to be blocked. That is trivial VPN bypass even when block all connections outside VPN is enabled, and trivial deanonymization attack too. Makes me want to cry. Still, it shouldn't matter in your case.. unless in fact you have been seeding without going through the VPN, which kind of sounds somewhat likely now..
I think I need to check a few things with the VPN implementation. Like, can an app obtain IP addresses from non-VPN network interfaces and send them out as possible connection points for incoming traffic. That alone would ruin any anonymity VPN would give, even if incoming connections are now blocked. I wished AOSP would just redo their VPN implementation from scratch in an actually secure way.. like how QubesOS have designed theirs. Seems like AOSP has done a minimal effort implementation of VPN that is just enough to be able to connect to corporate networks or the like, and not considered security or anonymity at all. Even if we patch up many leaks, we are doomed to miss something. An actual secure design from scratch would have given strong guarantees.
@H7oUt @ryrona aside of the provided link (thank you for the source!) explaining the changes mentioned in the top post, here's another theory. Disclaimer: I'm not knowledgeable enough to say it really works this way, but here goes.
Sometimes you can see you have seeds from the swarm, but no traffic comes in nor out. I think the issue may be a byproduct of the 'required encryption' setting. Meaning, we all would like our data to be encrypted at the very least while in transition, hence this setting is absolutely necessary, but at the same time others may not have it set. So as a result, we see seeds / peers, but can't actually exchange any data with them, because we require encryption and they can't provide it. Again, this is a theory. I haven't analyzed any code or even logs to say it works this way.
Anyway, ryrona's question is fair, are you sure there are other participants in the swarm?
Android VPN implementation is not as bad as iOS, which requires non-VPN connection to iCloud before VPN connects after rebooting phone. Apple designed iOS VPN to be on-demand, allowing apps to override them. The only way around it is using ControlD or NextDNS apps and force them to block all domains, except the ones needed by VPN app. Or just block all domain resolution completely and manually enable IP-based VPN apps, like the official WireGuard for iOS, after every reboot.
VPN kill switches are best when based on routing table metrics. If there is only one table, then all user-space apps are forced to use VPN tunnel. Maybe kernel-space parts of OS can bypass that, but do they use their own routing table?
thmf Sometimes you can see you have seeds from the swarm, but no traffic comes in nor out. I think the issue may be a byproduct of the 'required encryption' setting. Meaning, we all would like our data to be encrypted at the very least while in transition, hence this setting is absolutely necessary, but at the same time others may not have it set. So as a result, we see seeds / peers, but can't actually exchange any data with them, because we require encryption and they can't provide it.
Actually, you won't even be able to connect to peers that do not support encryption if you require encryption. So they should not show up as connected, or at most only momentarily while trying to connect to them.
When you connect to a seed, but they won't send you any data, it is almost always because they don't have any spare bandwidth to seed to you too, or you don't have any spare bandwidth to download from them too, or they actually don't have the data, that is, they are fake peers just monitoring the swarm.
When someone that doesn't themselves have 100% of the data of a torrent connects to you, but still does not request any data from you, that is almost always because they don't want any more data, at least not at this point in time. For torrents that contain multiple files, they might have picked to only download some of them. Or they have paused the download to allow for other torrents to finish first. Or they simply to not have enough spare bandwidth to download from you too.
H7oUt Android VPN implementation is not as bad as iOS, which requires non-VPN connection to iCloud before VPN connects after rebooting phone. Apple designed iOS VPN to be on-demand, allowing apps to override them.
... okay.
There is always worse implementations it seems.
H7oUt VPN kill switches are best when based on routing table metrics.
If the VPN implementation is correctly designed, kill switches shouldn't even be needed. The VPN should be impossible to bypass by design. Unfortunately almost all operating systems gets it wrong or doesn't care, which is why we need them.