[Bug]: Problems with tunnel access under Android 17 #118

framstag commented 2026年07月02日 22:24:32 +02:00

Please confirm that:

• I have searched the issues and didn't find my bug or an answer to my question
• My bug is about JetBird and not something upstream

What is your JetBird version?

Current / 1.8.2

What make/model is your device?

Pixel 8

What OS and version are you running?

Android 17

What happened?

I have strange effects I'm not sure if they are a problem of Android 17, Netbird Server, Netbird Client (library) or the Android client apps. I can reproduce the problem partially with the official client but completely with JetBird. I assume that it is a problem between Android 17 and the netbird client library.

Initial problem was that I was not able to access my Vaultwarden instance using the Bitwarden Client. Further testing shows that the problem occurs with other apps, too, but not all. It occured after updating to Android 17 and it looks like it occured after updating certain apps after the Android update.

My general setup:

• self-hosted
• Classic setup with caddy in a VPS
• Subdomains with official DNS IPs being netbird internal IPs (example: vw. => 100.x.x.x.)

The problem can get reproduced with the official client using the Bitwarden client and Termux. In both cases:

• The IP can get resolved on the client as seen from logs
• A connect stalls and timeouts
• The problem does not occures with firefox, DavX and other apps (no recent updates)

The problem seem to be reproducable with Jetbird for all apps (initial installation after Android update (>= today, I was not aware of it before)).

For official Client:

• Connect is claimed to be successful
• A Net Analyser instance can ping, traceroute and DNS resolve the host.
• LanDroid shows a reasonable routing table and can do a successful SSL check
• HTTP Shortcuts can call the server successfully
• Firefox can login
• But curl in Termux is hanging and nc gets timeout

For JetBird:

• getInfo got error 255
• warnings regarding rosenpass
• Warning regarding wireguard timeouts? (=> Problem?)
• No errors in log
• Connect is claimed to be successful
• Peers are claimed to be connected
• Firefox hangs on server call
• Bitwarden hangs
• LanDroid has error
• Net Analyser cannot ping or traceroute
• All other tunnel using apps hang
• Peer details show no bytes send/received

AI claims that VPN code in Android 17 was changed, so that might be a trigger.

I'm lost, I have no idea how to analyze this problem any further. The only pattern I see is setup timeing, though LanDroid worked, even it was installed today, Net Analyser was updated today and also shows no problem)

Versions:

• Netbird server and clients current (depending on OS)
• I have to two routing peers (0.74.1 and 0.73.2)

Any ideas?

Logs

No response

### Please confirm that: - [x] I have searched the [issues](https://codeberg.org/bg443/JetBird/issues) and didn't find my bug or an answer to my question - [x] My bug is about JetBird and not something upstream ### What is your JetBird version? Current / 1.8.2 ### What make/model is your device? Pixel 8 ### What OS and version are you running? Android 17 ### What happened? I have strange effects I'm not sure if they are a problem of Android 17, Netbird Server, Netbird Client (library) or the Android client apps. I can reproduce the problem partially with the official client but completely with JetBird. I assume that it is a problem between Android 17 and the netbird client library. Initial problem was that I was not able to access my Vaultwarden instance using the Bitwarden Client. Further testing shows that the problem occurs with other apps, too, but not all. It occured after updating to Android 17 and it looks like it occured after updating certain apps after the Android update. My general setup: - self-hosted - Classic setup with caddy in a VPS - Subdomains with official DNS IPs being netbird internal IPs (example: vw.<domain> => 100.x.x.x.) The problem can get reproduced with the official client using the Bitwarden client and Termux. In both cases: - The IP can get resolved on the client as seen from logs - A connect stalls and timeouts - The problem does not occures with firefox, DavX and other apps (no recent updates) The problem seem to be reproducable with Jetbird for *all* apps (initial installation after Android update (>= today, I was not aware of it before)). For official Client: - Connect is claimed to be successful - A Net Analyser instance can ping, traceroute and DNS resolve the host. - LanDroid shows a reasonable routing table and can do a successful SSL check - HTTP Shortcuts can call the server successfully - Firefox can login - But curl in Termux is hanging and nc gets timeout For JetBird: - getInfo got error 255 - warnings regarding rosenpass - Warning regarding wireguard timeouts? (=> Problem?) - No errors in log - Connect is claimed to be successful - Peers are claimed to be connected - Firefox hangs on server call - Bitwarden hangs - LanDroid has error - Net Analyser cannot ping or traceroute - All other tunnel using apps hang - Peer details show no bytes send/received AI claims that VPN code in Android 17 was changed, so that *might* be a trigger. **I'm lost, I have no idea how to analyze this problem any further. The only pattern I see is setup timeing, though LanDroid worked, even it was installed today, Net Analyser was updated today and also shows no problem)** Versions: - Netbird server and clients current (depending on OS) - I have to two routing peers (0.74.1 and 0.73.2) Any ideas? ### Logs _No response_

bg443 commented 2026年07月03日 17:57:08 +02:00

Before digging into it too much, it's worth noting that JetBird and NetBird's official Android client are likely not running the same client version. I see there was an update yesterday but it's not clear if this has been pushed to Google Play yet (I don't have any devices with the Play store).

According to the Android 17 release post, local network access has been restricted without requesting a permission from the user. Unfortunately they never define what "local" is (i.e. localhost? CGNAT?)

I'm lost, I have no idea how to analyze this problem any further.

You're not alone. I am able to reproduce this behaviour now that I have a device on Android 17. I've tried adding the new local network permission just in case, but that did not change anything.

This leads me to believe (along with the fact it's happening in the official client) that NetBird needs to push some changes in order to get the tunnel working properly on Android 17. I don't have a GitHub account so I am unable to open an issue there. I also don't see any open issues about this problem either.

Before digging into it too much, it's worth noting that JetBird and NetBird's official Android client are likely not running the same client version. I see there was an update [yesterday](https://github.com/netbirdio/android-client/commit/dc40e04afa3c87b2360beffd376a99e5bc6cd335) but it's not clear if this has been pushed to Google Play yet (I don't have any devices with the Play store). According to the [Android 17 release post](https://android-developers.googleblog.com/2026/06/Android-17.html), local network access has been restricted without requesting a permission from the user. Unfortunately they never define what "local" is (i.e. localhost? CGNAT?) >I'm lost, I have no idea how to analyze this problem any further. You're not alone. I am able to reproduce this behaviour now that I have a device on Android 17. I've tried adding the new local network permission just in case, but that did not change anything. This leads me to believe (along with the fact it's happening in the official client) that NetBird needs to push some changes in order to get the tunnel working properly on Android 17. I don't have a GitHub account so I am unable to open an issue there. I also don't see any open issues about this problem either.

framstag commented 2026年07月03日 18:31:23 +02:00

Thanks for your response. The official Android Client uses a rather old library version. It will not automatically releases with each netbird release. Looking at the repository the client is 0.72.4.

JetBird uses a newer client.

There was a new Netbird release just a few minutes ago (0.74.2). Does not look like anything relevant regarding above the problem was changed. Problem are still there after server update. But peers still use 0.74.1, so...who knows.

I can open an issue in GitHub, but experience shows that they are ignored.

You are referring to "Local network protections: Apps targeting SDK 37 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORKpermission for broad, persistent access.". So possibly this is not a Netbird problem, but the problem of applications, that have to communicate through a tunnel on my system? How can I check the permissions on my system to see if there is a pattern?

Also, this would not explain, why JetBird tunnels are always not usable, while NetBird tunnels are sometimes not usable by specific applications.

I used perplexity.ai for a more in deep definition:

• LAN is specified as access to local networks (192.168..., 10., 172.16....). For 100.64.x.x the AI is unsure and suggests to play safe.
• The permission is required explicitly if target is 17+, for older targets, it is implied by using INTERNET.
• So, my interpretation: If the new permission is a problem, both VPN and Client must enforce the permission at runtime (!), to make use - if they target Android 17, if not, they might still make use of the VPN.

So how can I check the target version of the Apps on my mobile and check, if they enforce the right at runtime? Possibly I then can proove the pattern. And how does Android judges 100.64.x.x in this case?

I'm will to do further investigation, as long, as I know how...

Thanks for your response. The official Android Client uses a rather old library version. It will not automatically releases with each netbird release. Looking at the repository the client is 0.72.4. JetBird uses a newer client. There was a new Netbird release just a few minutes ago (0.74.2). Does not look like anything relevant regarding above the problem was changed. Problem are still there after server update. But peers still use 0.74.1, so...who knows. I can open an issue in GitHub, but experience shows that they are ignored. You are referring to "Local network protections: Apps targeting SDK 37 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORKpermission for broad, persistent access.". So possibly this is not a Netbird problem, but the problem of applications, that have to communicate through a tunnel on my system? How can I check the permissions on my system to see if there is a pattern? Also, this would not explain, why JetBird tunnels are always not usable, while NetBird tunnels are sometimes not usable by specific applications. I used perplexity.ai for a more in deep definition: * LAN is specified as access to local networks (192.168..., 10., 172.16....). For 100.64.x.x the AI is unsure and suggests to play safe. * The permission is required explicitly if target is 17+, for older targets, it is implied by using INTERNET. * So, my interpretation: If the new permission is a problem, both VPN and Client must enforce the permission at runtime (!), to make use - if they target Android 17, if not, they might still make use of the VPN. So how can I check the target version of the Apps on my mobile and check, if they enforce the right at runtime? Possibly I then can proove the pattern. And how does Android judges 100.64.x.x in this case? I'm will to do further investigation, as long, as I know how...

framstag commented 2026年07月03日 18:43:10 +02:00

Netbird is target SDK 35 and enlists the permission
JetBird is target SDK 37 but does not enlist the permission
Bitwarden is target SDK 37 and enlists the permission
DavX ist target SDK 36 and enlists the permission
Termux is target SDK 37 and does not enlist the permission
Firefox is SDK 36 and enlists the permission
...
KI claims, that 100.64.x.x is LAN as in the definition of Android

However it also says, that permission must not only be enlisted but also checked and requested before actual access. SO there still could be problems in above apps.

Netbird is target SDK 35 and enlists the permission JetBird is target SDK 37 but does not enlist the permission Bitwarden is target SDK 37 and enlists the permission DavX ist target SDK 36 and enlists the permission Termux is target SDK 37 and does not enlist the permission Firefox is SDK 36 and enlists the permission ... KI claims, that 100.64.x.x is LAN as in the definition of Android However it also says, that permission must not only be enlisted but also checked and requested before actual access. SO there still could be problems in above apps.

framstag commented 2026年07月03日 19:07:29 +02:00

Netbird is target SDK 35 and enlists the permission
JetBird is target SDK 37 but does not enlist the permission
Bitwarden is target SDK 37 and enlists the permission
DavX ist target SDK 36 and enlists the permission
Termux is target SDK 37 and does not enlist the permission
Firefox is SDK 36 and enlists the permission
...
KI claims, that 100.64.x.x is LAN as in the definition of Android

However it also says, that permission must not only be enlisted but also checked and requested before actual access.

Netbird is target SDK 35 and enlists the permission JetBird is target SDK 37 but does not enlist the permission Bitwarden is target SDK 37 and enlists the permission DavX ist target SDK 36 and enlists the permission Termux is target SDK 37 and does not enlist the permission Firefox is SDK 36 and enlists the permission ... KI claims, that 100.64.x.x is LAN as in the definition of Android However it also says, that permission must not only be enlisted but also checked and requested before actual access.

framstag commented 2026年07月03日 19:10:14 +02:00

After granting Bitwarden the "Geräte in der Nähe" permission via settings dialog, it is now again able to use the tunnel.

So I suggest that you also enlist the permission in JetBird and check and request during runtime. However to actually make use of the tunnel, the other side also must request the permission, too.

Thanks for the hint that in the end helped me fix my problem myself. I hope that it also helps you in improving JetBird. I can do further tests, if you did.

I would be happy to switch to JetBird as my primary Android client :-)

After granting Bitwarden the "Geräte in der Nähe" permission via settings dialog, it is now again able to use the tunnel. So I suggest that you also enlist the permission in JetBird and check and request during runtime. However to actually make use of the tunnel, the other side also must request the permission, too. Thanks for the hint that in the end helped me fix my problem myself. I hope that it also helps you in improving JetBird. I can do further tests, if you did. I would be happy to switch to JetBird as my primary Android client :-)

bg443 commented 2026年07月03日 22:11:58 +02:00

v1.8.3 should have what you need

[`v1.8.3`](https://codeberg.org/bg443/JetBird/releases/tag/v1.8.3) should have what you need

framstag commented 2026年07月04日 22:25:47 +02:00

I can confirm that after a workaround for #121 the tunnel works. You can close the issue.

I can confirm that after a workaround for #121 the tunnel works. You can close the issue.