Split tunnelling fails for LAN between two Android devices

[dairefagan]

Please complete the following checklist (by adding [x]):

• I have searched open and closed issues for duplicates
• This isn't a feature request
• This is not a report about my app not working as expected

---

Split tunnelling fails for local network connections between two Android devices

Summary

Split tunnelling in ProtonVPN on Android fails to properly exclude an app (Grayjay) from the VPN tunnel when performing local network device-to-device sync. The app is added to the exclusion list and the devices are on the same LAN, yet direct local connections do not work until the VPN is fully disabled on both ends.

Initially (June 2025), sync did not work at all with the VPN active. As of August 2025, a partial workaround emerged: if the VPN is disabled on both devices to establish the initial handshake, sync continues to work after re-enabling the VPN — suggesting the split tunnel exclusion fails specifically during initial connection establishment but works for already-established connections. As of December 2025, this behaviour affects both Android-to-Android and Linux-to-Android connections.

Environment

• Device 1: Google Pixel 6a — Android 15
• Device 2: Samsung Galaxy Tab A7 — Android 12
• ProtonVPN version: 5.15.9.4
• App being excluded: Grayjay (v320)
• Network: Both devices on the same local Wi-Fi network / subnet

ProtonVPN Configuration (Both Devices)

• Kill switch: Disabled
• Split tunnelling: Enabled
• Split tunnelling mode: Standard ("Selected apps and IP addresses are excluded from the VPN connection")
• Grayjay: Added to excluded apps list
• LAN connections: Enabled (under Advanced settings)
• Additionally tested: Static IPs assigned to both devices and added to the excluded IP addresses list (note: ProtonVPN would not accept a subnet entry e.g. 192.168.x.0/24, so individual device IPs were used)

Steps to reproduce

1. Install ProtonVPN on two Android devices on the same local Wi-Fi network.
2. Configure split tunnelling as described above on both devices.
3. Connect both devices to the VPN.
4. Open Grayjay on both devices and attempt to sync (device-to-device, local network).
5. Observe that the sync screen is stuck on "Handshaking" indefinitely.

Expected behaviour

Since Grayjay is excluded from the VPN tunnel via split tunnelling, local network traffic from the app should bypass the VPN and connect directly to the other device on the LAN. The sync handshake should complete successfully.

Actual behaviour

The sync is stuck on "Handshaking" and never completes. This persists regardless of whether the app alone is excluded or both the app and individual device IPs are excluded.

Key Observation (Workaround)

When the issue was first reported (June 2025), sync did not work at all with the VPN active. By August 2025, a partial improvement was observed: if the VPN is disabled on both devices first, the sync handshake completes successfully. After re-enabling the VPN, the sync session continues to work. However, any new connection attempt while the VPN is active still fails. This suggests:

• The split tunnel exclusion may not be applied during initial connection establishment / socket binding
• Once a connection is already established, it is correctly excluded from the tunnel
• The issue is specific to new outbound connection attempts from excluded apps

Additional context

• PC-to-Android: As of August 2025, syncing from a PC (Linux) to either Android device worked with split tunnelling. However, as of December 2025, the initial handshake now also fails for Linux-to-Android unless the VPN is disabled on both ends first.
• Other apps work: Split tunnelling works correctly for other excluded apps on the same devices and network.
• Persistent: The issue has been present since June 2025 and is still reproducible as of December 2025.

Possible root causes to investigate

1. Multicast/broadcast traffic not excluded: The app may rely on mDNS, SSDP, or UDP broadcast for device discovery on the LAN. Split tunnelling may only exclude unicast TCP/UDP traffic from the named app, while multicast/broadcast packets are still routed through the VPN tunnel.

2. DNS resolution for local devices: If local hostname resolution is routed through the VPN's DNS, it may fail to resolve local device addresses.

3. Socket binding timing: The split tunnel exclusion may not be applied at socket creation time, causing the initial handshake packets to go through the tunnel before the exclusion rule takes effect.

4. Android-to-Android specific: Both devices running ProtonVPN with split tunnelling means both sides of the connection need to correctly exclude the traffic. A failure on either side would prevent the connection.

Reference

This issue was originally reported at futo-org/grayjay-android#2342 and directed to ProtonVPN for further investigation.

[flynnjustin24]

dot.libredns.gr