VPNs frequently disconnect when used in User 0 and User 10 (Personal and Work profiles) simultaneously

[e-t-l]

To make issues more manageable, I would appreciate it if you fill out the following details as applicable:

General information

1. Android 13
2. GrapheneOS
3. Google Pixel 7
4. App version 0.7.22

Description of the issue

When two user profiles (in this case the personal and work profiles) are both running the OpenVPN for Android app, there seems to be some sort of interaction/conflict that causes one or both of them to disconnect.

I'm not sure if it's related to #1293 and/or #1299 since it seems to happen more frequently (but not exclusively or consistently) overnight or when switching networks. I do get the "OpenVPN3 thread finished" message, but switching back to OpenVPN v2 didn't seem to make a difference, nor did having one profile on v3 and one on v2. Per #1299 I'm currently trying having "Bypass VPN for local networks" disabled but I haven't had that changed for long enough to determine if it has completely solved the issue.

Suggestion: The RethinkDNS app evidently has some way of routing ALL users' traffic (aka from both personal and work profiles) through one VPN app installed for only user 0. If we can identify how RethinkDNS accomplishes this, then this issue would be moot, because OpenVPN would not have to be running on multiple user profiles simultaneously. It would also have obvious improvements for battery/system performance. Do you think that's an option worth exploring?

Log (if applicable)

(Haven't been able to catch a log, as I'm not 100% sure when it happens. I think it might be when switching networks.)

Configuration files (same for both user profiles)

# Config for OpenVPN 3 C++
client
verb 4
connect-retry 2 300
resolv-retry 60
dev tun
remote-random
auth-user-pass
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
client-cert-not-required
<tls-auth>
# 2048 bit OpenVPN static key
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-auth>
key-direction 1
route-ipv6 ::/0
route 0.0.0.0 0.0.0.0 vpn_gateway
dhcp-option DNS 10.10.10.10
dhcp-option DOMAIN blinkt.de
mssfix
nobind
remote-cert-tls server
data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC
cipher AES-256-CBC
auth SHA512
persist-tun
# persist-tun also enables pre resolving to avoid DNS resolve problem
preresolve
# Custom configuration options
# You are on your on own here :)
# These options found in the config file do not map to config settings:
resolv-retry infinite 
reneg-sec 0 
fast-io 

# Connection Options are at the end to allow global options (and global custom options) to influence connection blocks
<connection>
remote 156.146.54.81 51820 udp
tun-mtu-extra 32 

</connection>
<connection>
remote 156.146.54.81 80 udp
tun-mtu-extra 32 

</connection>
<connection>
remote 156.146.54.81 5060 udp
tun-mtu-extra 32 

</connection>
<connection>
remote 156.146.54.81 1194 udp
tun-mtu-extra 32 

</connection>
<connection>
remote 156.146.54.81 4569 udp
tun-mtu-extra 32 

</connection>

[schwabe]

What is the reason in the internal log of the app why it disconnects?

VPN for different user accounts are to my knowlege always separated on Android phone and I am not aware of any API or workarounds around that and it should also not be possible.

[e-t-l]

Ok, it just happened again so I was able to copy some of the internal logs. It looks like it's these two entries, alternating one after the other. I assume it has something to do with the VPN retrying to connect? Since there's hundreds of them. It doesn't let me scroll far enough back in time to see the log at the actual time of disconnect.

10:33 PM Unhandled exception: Invalid packet data!

java.io.IOException: Invalid packet data!
	at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.readInt(StreamCapture.java:125)
	at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.readPacket(StreamCapture.java:132)
	at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.run(StreamCapture.java:222)
	at java.lang.Thread.run(Thread.java:1012)

10:33 PM Unhandled exception: write failed: EPIPE (Broken pipe)

java.io.IOException: write failed: EPIPE (Broken pipe)
	at libcore.io.IoBridge.write(IoBridge.java:651)
	at java.io.FileOutputStream.write(FileOutputStream.java:401)
	at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.writeThrough(StreamCapture.java:185)
	at de.blinkt.openvpn.core.capture.StreamCapture$TransferThread.run(StreamCapture.java:275)
	at java.lang.Thread.run(Thread.java:1012)
Caused by: android.system.ErrnoException: write failed: EPIPE (Broken pipe)
	at libcore.io.Linux.writeBytes(Native Method)
	at libcore.io.Linux.write(Linux.java:296)
	at libcore.io.ForwardingOs.write(ForwardingOs.java:943)
	at libcore.io.BlockGuardOs.write(BlockGuardOs.java:448)
	at libcore.io.ForwardingOs.write(ForwardingOs.java:943)
	at libcore.io.IoBridge.write(IoBridge.java:646)
	... 4 more

Also, regarding

VPN for different user accounts are to my knowlege always separated on Android phone and I am not aware of any API or workarounds around that and it should also not be possible.

I did link you to the source code of a VPN that does exactly that. The good news is that it definitely is possible, and we can even look at how they did it!

[schwabe]

Are you sure that you are using my app? That stacktrace including a class (StreamCapture.java) that is not part of my source code.

[e-t-l]

It's the pDNSf fork (https://github.com/IngoZenz/ics-openvpn/), where the only difference is that DNS queries are sent to port 5300 by default, which uses that streamcapture library.

From that fork's readme: If the DNS option is not used,

OpenVPN for personalDNSfilter will behave exactly as the original OpenVPN for Android application.

If you think the issue specifically arises from streamcapture integration, that's good to know. But it seems unlikely, given how we've been discussing that it's specifically a conflict that occurs when running a VPN on multiple profiles

[schwabe]

@e-t-l yes but your stacktrace includes those streamcapture things. So something might break that. And the streamcapture integration messes quite a bit with the VPNservice. So all I see is that streamcapture stuff somehow breaks but I have real idea what is actually going on. From a quick glance at the trace you posted it seems that streamcapture throws an exception and after that your connection breaks. Which points at streamcapture as the culprit.

[e-t-l]

I see what you mean. I can uninstall and replace it with the unmodified version to see if the logs change. So have you not been able to replicate these unexpected disconnects when you run OpenVPN in Personal and Work profiles simultaneously?

(Edit: I thought I finally captured a log that's different from the other two. Turns out it's just the same. It's hard to copy the stack traces because they go by so fast. Not sure why, since it doesn't even look like the VPN is trying to reconnect. Do you recognize any of these exceptions, like EPIPE or Invalid Packet Data?)

[schwabe]

I know EPIPE and Invalid Packet Data are and they are very likely to be caused by streamcapture as well. So for me it is still very likely to assume that this is a problem of those modifications and not of my app.

[schwabe]

Closing this issue for now until we know that it is really my app and not the modification

[ignoramous]

rdns dev here

Suggestion: The RethinkDNS app evidently has some way of routing ALL users' traffic (aka from both personal and work profiles) through one VPN app installed for only user 0.

Don't think that's possible and rdns most certainly doesn't do anything special (even if it did, it won't have worked without root).