Android app: Network routes are not working #334

Open
opened 2025-11-20 05:09:47 -05:00 by saavagebueno · 16 comments
Owner

Originally created by @kdre on GitHub (May 15, 2023).

Originally assigned to: @pappz on GitHub.

Describe the problem
I cannot access defined network routes.

To Reproduce
Define network routs in the web interface (In my case: 192.168.0.0/24).
Test that network traffic is correctly routed on other clients (e.g. access internal webserver with http://192.168.0.1 in a browser).
Test that network traffic is correctly routed on android -> Devices cannot be accessed.

Expected behavior
Network traffic should be correctly routed to internal clients according to the defined network routes.

Tested netbird version: 0.0.7
Mobile: Samsung Galaxy S23 Ultra (Android 13)

Originally created by @kdre on GitHub (May 15, 2023). Originally assigned to: @pappz on GitHub. **Describe the problem** I cannot access defined network routes. **To Reproduce** Define network routs in the web interface (In my case: 192.168.0.0/24). Test that network traffic is correctly routed on other clients (e.g. access internal webserver with http://192.168.0.1 in a browser). Test that network traffic is correctly routed on android -> Devices cannot be accessed. **Expected behavior** Network traffic should be correctly routed to internal clients according to the defined network routes. Tested netbird version: 0.0.7 Mobile: Samsung Galaxy S23 Ultra (Android 13)
saavagebueno added the waiting-feedbackAndroid labels 2025-11-20 05:09:47 -05:00
Author
Owner

@pappz commented on GitHub (May 15, 2023):

@kdre Could you share with me the exact version name of the Android application?

@pappz commented on GitHub (May 15, 2023): @kdre Could you share with me the exact version name of the Android application?
Author
Owner

@mlsmaycon commented on GitHub (May 15, 2023):

@kdre can you confirm if the issue happens after reconnecting the client? Android limits route configuration to when the interface is created, so if you updated any route for the Android client after connected, you will have to reconnect.

@mlsmaycon commented on GitHub (May 15, 2023): @kdre can you confirm if the issue happens after reconnecting the client? Android limits route configuration to when the interface is created, so if you updated any route for the Android client after connected, you will have to reconnect.
Author
Owner

@kdre commented on GitHub (May 16, 2023):

@kdre Could you share with me the exact version name of the Android application?

@pappz The exact version is 0.0.7.

@kdre can you confirm if the issue happens after reconnecting the client? Android limits route configuration to when the interface is created, so if you updated any route for the Android client after connected, you will have to reconnect.

@mlsmaycon Yes, I confirm that the issue happens even after reconnecting (the network routes were defined long before I installed the android app). I just tested it again right now. No success.
When I open a web browser on my mobile while netbird is connected and try to access either "http://192.168.0.1" or "http://fritz.box" then nothing happens. The request times out after some time.

If it matters: I use a Samsung Galaxy S23 Ultra (Android 13)

@kdre commented on GitHub (May 16, 2023): > @kdre Could you share with me the exact version name of the Android application? @pappz The exact version is 0.0.7. > @kdre can you confirm if the issue happens after reconnecting the client? Android limits route configuration to when the interface is created, so if you updated any route for the Android client after connected, you will have to reconnect. @mlsmaycon Yes, I confirm that the issue happens even after reconnecting (the network routes were defined long before I installed the android app). I just tested it again right now. No success. When I open a web browser on my mobile while netbird is connected and try to access either "http://192.168.0.1" or "http://fritz.box" then nothing happens. The request times out after some time. If it matters: I use a Samsung Galaxy S23 Ultra (Android 13)
Author
Owner

@mlsmaycon commented on GitHub (May 16, 2023):

Thanks @kdre, can you confirm that the network route is being distributed to a group that the android device is part of and that the device and the routing peer are connected?

@mlsmaycon commented on GitHub (May 16, 2023): Thanks @kdre, can you confirm that the network route is being distributed to a group that the android device is part of and that the device and the routing peer are connected?
Author
Owner

@kdre commented on GitHub (May 17, 2023):

@mlsmaycon Yes, I can confirm that my mobile device is in the group that receives the network routes. In fact, I only have an "all" group ('1'). And the netbird website shows that all clients are in group '1' and also that the network routes are for group '1'.

I can further confirm that the routing peer is up and running and connected (there are two defined for redundancy, but only one is currently online).

I am currently sitting in my office and I just opened a web browser on my notebook which is connected to the netbird network and accessed http://192.168.0.1 which is my router at home. It just works. Even dns is correctly resolved (I can access http://fritz.box).

When I connect to the netbird network on my mobile and try to do the same in a browser then it times out. Tested on chrome, Samsung browser and DuckDuckGo.

edit:
I just updated the android netbird client to version 0.0.8. The problem still exists.

@kdre commented on GitHub (May 17, 2023): @mlsmaycon Yes, I can confirm that my mobile device is in the group that receives the network routes. In fact, I only have an "all" group ('1'). And the netbird website shows that all clients are in group '1' and also that the network routes are for group '1'. I can further confirm that the routing peer is up and running and connected (there are two defined for redundancy, but only one is currently online). I am currently sitting in my office and I just opened a web browser on my notebook which is connected to the netbird network and accessed http://192.168.0.1 which is my router at home. It just works. Even dns is correctly resolved (I can access http://fritz.box). When I connect to the netbird network on my mobile and try to do the same in a browser then it times out. Tested on chrome, Samsung browser and DuckDuckGo. edit: I just updated the android netbird client to version 0.0.8. The problem still exists.
Author
Owner

@gerthomas commented on GitHub (May 25, 2023):

Routes to private networks works for me using Android app.

Tested netbird version: 0.0.8
Mobile: Samsung Galaxy S22 Ultra (Android 13)

@gerthomas commented on GitHub (May 25, 2023): Routes to private networks works for me using Android app. Tested netbird version: 0.0.8 Mobile: Samsung Galaxy S22 Ultra (Android 13)
Author
Owner

@buster39 commented on GitHub (May 28, 2023):

Yes, on Android 13 it works on two devices here.
On Android 9 (Fire HD 10-Tablet) not.

@buster39 commented on GitHub (May 28, 2023): Yes, on Android 13 it works on two devices here. On Android 9 (Fire HD 10-Tablet) not.
Author
Owner

@Akruidenberg commented on GitHub (Jul 29, 2023):

Same here. Android app will not connect to the server where network routes are applied. Linux and Windows are working. Android and Docker are not. Android version is LineageOS 20, running on Oneplus 6.

@Akruidenberg commented on GitHub (Jul 29, 2023): Same here. Android app will not connect to the server where network routes are applied. Linux and Windows are working. Android and Docker are not. Android version is LineageOS 20, running on Oneplus 6.
Author
Owner

@thehoff commented on GitHub (Sep 19, 2023):

android 13. pixel 7. connects but cant use advertised routes.

@thehoff commented on GitHub (Sep 19, 2023): android 13. pixel 7. connects but cant use advertised routes.
Author
Owner

@soakes commented on GitHub (Apr 1, 2024):

Hi, I am also experencing the same issue on android 14 running on a Pixel 6 Pro.

I can confirm that the network routes are being distributed to a group which both mobile client and the servers have access to. The "what I call" private link pairs work (thats your CGNAT range), but actual routed blocks do not.

The Linux based networks, all can communicate correctly, its only the android client that cant reach anything within the networks apart from the CGNAT ranges.

Any thoughts?

Update

Doing some digging, it seems the same issue is happening on the OSX client as well. This is using the netbird client inside brew.

Using a netbird status -d shows:

{... snip}
 hh***.netbird.cloud:
  NetBird IP: 100.92.**.**
  Public key: pEkLEL************************
  Status: Connected
  -- detail --
  Connection type: P2P
  Direct: true
  ICE candidate (Local/Remote): srflx/host
  ICE candidate endpoints (Local/Remote): **.**.**.**:51820/**.**.**.**:51820
  Last connection update: 2024-04-01 10:07:16
  Last WireGuard handshake: 2024-04-01 10:07:16
  Transfer status (received/sent) 692 B/880 B
  Quantum resistance: false
  Routes: -
  Latency: 9.513138ms

The bit I would like to point out is the routes line, you can see its blank.

If you check like the same peer on one of the linux gateways, you will see its present.

{... snip}
 hh***.netbird.cloud:
NetBird IP: 100.92.*******
Public key: pEkLEL*********************
Status: Connected
-- detail --
Connection type: P2P
Direct: true
ICE candidate (Local/Remote): host/host
ICE candidate endpoints (Local/Remote): **.**.**.**:51820/**.**.**.**:51820
Last connection update: 2024-04-01 05:47:30
Last WireGuard handshake: 2024-04-01 09:11:36
Transfer status (received/sent) 23.6 MiB/242.6 MiB
Quantum resistance: false
Routes: 10.26.xx.xx/24
Latency: 6.066276ms

I suspect the same issue is happning with the android client but I have no easy way to confirm this.

Assuming what I suspect is going on, how can we get the routes to populate to android/osx clients?

@soakes commented on GitHub (Apr 1, 2024): Hi, I am also experencing the same issue on android 14 running on a Pixel 6 Pro. I can confirm that the network routes are being distributed to a group which both mobile client and the servers have access to. The "what I call" private link pairs work (thats your CGNAT range), but actual routed blocks do not. The Linux based networks, all can communicate correctly, its only the android client that cant reach anything within the networks apart from the CGNAT ranges. Any thoughts? *Update* Doing some digging, it seems the same issue is happening on the OSX client as well. This is using the netbird client inside brew. Using a `netbird status -d` shows: ``` {... snip} hh***.netbird.cloud: NetBird IP: 100.92.**.** Public key: pEkLEL************************ Status: Connected -- detail -- Connection type: P2P Direct: true ICE candidate (Local/Remote): srflx/host ICE candidate endpoints (Local/Remote): **.**.**.**:51820/**.**.**.**:51820 Last connection update: 2024-04-01 10:07:16 Last WireGuard handshake: 2024-04-01 10:07:16 Transfer status (received/sent) 692 B/880 B Quantum resistance: false Routes: - Latency: 9.513138ms ``` The bit I would like to point out is the routes line, you can see its blank. If you check like the same peer on one of the linux gateways, you will see its present. ``` {... snip} hh***.netbird.cloud: NetBird IP: 100.92.******* Public key: pEkLEL********************* Status: Connected -- detail -- Connection type: P2P Direct: true ICE candidate (Local/Remote): host/host ICE candidate endpoints (Local/Remote): **.**.**.**:51820/**.**.**.**:51820 Last connection update: 2024-04-01 05:47:30 Last WireGuard handshake: 2024-04-01 09:11:36 Transfer status (received/sent) 23.6 MiB/242.6 MiB Quantum resistance: false Routes: 10.26.xx.xx/24 Latency: 6.066276ms ``` I suspect the same issue is happning with the android client but I have no easy way to confirm this. Assuming what I suspect is going on, how can we get the routes to populate to android/osx clients?
Author
Owner

@Damix48 commented on GitHub (Nov 17, 2024):

Is this still an issue? I would like to try Netbird but I need this feature on my phone

@Damix48 commented on GitHub (Nov 17, 2024): Is this still an issue? I would like to try Netbird but I need this feature on my phone
Author
Owner

@oscarchd commented on GitHub (Nov 21, 2024):

Problem still persist, I'm testing it out and found out all other nodes are able to see each other but Android devices connected to netbird are unable to see other nodes

PS: server and apps are latest version

@oscarchd commented on GitHub (Nov 21, 2024): Problem still persist, I'm testing it out and found out all other nodes are able to see each other but Android devices connected to netbird are unable to see other nodes PS: server and apps are latest version
Author
Owner

@Damix48 commented on GitHub (Nov 29, 2024):

Today I took some time to try Netbird again and found that this issue no longer exists. It's working now. Awesome!

@Damix48 commented on GitHub (Nov 29, 2024): Today I took some time to try Netbird again and found that this issue no longer exists. It's working now. Awesome!
Author
Owner

@nazarewk commented on GitHub (Apr 28, 2025):

Hello @kdre,

We're currently reviewing our open issues and would like to verify if this problem still exists in the latest NetBird version.

Could you please confirm if the issue is still there?

We may close this issue temporarily if we don't hear back from you within 2 weeks, but feel free to reopen it with updated information.

Thanks for your contribution to improving the project!

@nazarewk commented on GitHub (Apr 28, 2025): Hello @kdre, We're currently reviewing our open issues and would like to verify if this problem still exists in the [latest NetBird version](https://github.com/netbirdio/netbird/releases). Could you please confirm if the issue is still there? We may close this issue temporarily if we don't hear back from you within **2 weeks**, but feel free to reopen it with updated information. Thanks for your contribution to improving the project!
Author
Owner

@atomlab commented on GitHub (May 1, 2025):

Hello @nazarewk, I confirm that the problem still exists. I will describe my case below. Before the diagnosis, I updated all versions to the latest release.

Problem

Network routes through a NetBird gateway node (100.70.200.77) for resources 100.70.169.36 and 100.70.47.126 work on Linux but fail on Android. All devices are in the gateway-users group with ACLs allowing access. The gateway is reachable from Android, but resources are not. tcpdump on the gateway node shows ICMP packets from Android only for the gateway, not the resources. But all packets coming from Linux are correctly displayed in tcpdump.

Steps to Reproduce

  1. Set up a NetBird network with:
    • Gateway node (100.70.200.77) routing to 100.70.169.36/32 and 100.70.47.126/32.
    • ACLs for gateway-users group allowing TCP (443) and ICMP.
  2. Connect Linux (v0.43.1) and Android (v0.34.0) clients.
  3. On Linux: Check routes (ip r), ping gateway and resources.
  4. On Android (via ADB): Check routes (ip route), ping gateway and resources.
  5. On gateway: Run tcpdump -ni wt0 icmp during pings.

Expected Behavior

Android and Linux clients should ping 100.70.169.36 and 100.70.47.126 via the gateway, with tcpdump showing ICMP packets for all pings.

Actual Behavior

  • Linux:
    • Route: 100.70.0.0/16 via wt0.
    • Pings to 100.70.200.77, 100.70.169.36, 100.70.47.126 succeed.
    • tcpdump shows all ICMP packets.
  • Android:
    • Route: 100.70.0.0/16 via tun0.
    • Ping to 100.70.200.77 succeeds; pings to 100.70.169.36, 100.70.47.126 fail (100% packet loss).
    • tcpdump shows ICMP packets only for 100.70.200.77.

Environment

  • NetBird Management: v0.43.1
  • Netbird Linux client on Gateway node: v0.43.1
  • Netbird Linux client on Desktop node: v0.43.1
  • Android Netbird Client: v0.34.0
  • Android version: Android 15 (Xiaomi 14)

Image

Image

Image

Image

Diagnostics

Linux Desktop Node

Checking the availability of resources is successful


% netbird version  
0.43.1

% ip a show dev wt0
wt0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 100.70.222.106/16 brd 100.70.255.255 scope global wt0
       valid_lft forever preferred_lft forever

% ip r | grep 100.70
100.70.0.0/16 dev wt0 proto kernel scope link src 100.70.222.106

% wg
interface: wt0
  public key: OnYukdYUGEh5zqCttiXq6WICXoFLBbaSJeRotGlNJRE=
  private key: (hidden)
  listening port: 51820
  fwmark: 0x1bd00

peer: ibJbTiGNdErXwhDwy+B7yN1n1MpdiacgJ7GYN9EXTHo=
  endpoint: 127.0.0.1:5
  allowed ips: 100.70.47.126/32, 100.70.169.36/32, 100.70.200.77/32
  latest handshake: 30 seconds ago
  transfer: 8.07 KiB received, 6.97 KiB sent
  persistent keepalive: every 25 seconds


## Successful ping to resource

% ping -c 3 -I wt0 100.70.169.36
PING 100.70.169.36 (100.70.169.36) from 100.70.222.106 wt0: 56(84) bytes of data.
64 bytes from 100.70.169.36: icmp_seq=1 ttl=63 time=93.4 ms
64 bytes from 100.70.169.36: icmp_seq=2 ttl=63 time=91.3 ms
64 bytes from 100.70.169.36: icmp_seq=3 ttl=63 time=101 ms
--- 100.70.169.36 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 91.253/95.112/100.635/4.006 ms


% ping -c 3 -I wt0 100.70.169.36             
PING 100.70.169.36 (100.70.169.36) from 100.70.222.106 wt0: 56(84) bytes of data.
64 bytes from 100.70.169.36: icmp_seq=1 ttl=63 time=93.2 ms
64 bytes from 100.70.169.36: icmp_seq=2 ttl=63 time=92.9 ms
64 bytes from 100.70.169.36: icmp_seq=3 ttl=63 time=96.2 ms
--- 100.70.169.36 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 92.852/94.096/96.193/1.491 ms

Android (via ADB)

Checking the availability of resources fails.


% adb devices                                  
List of devices attached
45d66e71        device

% adb shell ip a show dev tun0
tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 100.70.10.225/16 scope global tun0
       valid_lft forever preferred_lft forever

% adb shell ip route
100.70.0.0/16 dev tun0 proto kernel scope link src 100.70.10.225

## Successful ping to gateway
% adb shell ping -c 3 -I tun0 100.70.200.77
PING 100.70.200.77 (100.70.200.77) from 100.70.10.225 tun0: 56(84) bytes of data.
64 bytes from 100.70.200.77: icmp_seq=1 ttl=64 time=72.2 ms
64 bytes from 100.70.200.77: icmp_seq=2 ttl=64 time=107 ms
64 bytes from 100.70.200.77: icmp_seq=3 ttl=64 time=29.4 ms
--- 100.70.200.77 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 29.472/69.844/107.802/32.024 ms


## Failed ping to resource
% adb shell ping -c 3 -I tun0 100.70.47.126
PING 100.70.47.126 (100.70.47.126) from 100.70.10.225 tun0: 56(84) bytes of data.
--- 100.70.47.126 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2034ms


## Failed ping to resource
% adb shell ping -c 3 -I tun0  100.70.169.36             
PING 100.70.169.36 (100.70.169.36) from 100.70.10.225 tun0: 56(84) bytes of data.
--- 100.70.169.36 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2040ms

Notes

  • Unable to run wg show on Android (no wireguard-tools). There is no way to check the allowed ips addresses on Android.

Logs

@atomlab commented on GitHub (May 1, 2025): Hello @nazarewk, I confirm that the problem still exists. I will describe my case below. Before the diagnosis, I updated all versions to the latest release. ## Problem Network routes through a NetBird gateway node (`100.70.200.77`) for resources `100.70.169.36` and `100.70.47.126` work on Linux but fail on Android. All devices are in the `gateway-users` group with ACLs allowing access. The gateway is reachable from Android, but resources are not. `tcpdump` on the gateway node shows ICMP packets from Android only for the gateway, not the resources. But all packets coming from Linux are correctly displayed in tcpdump. ## Steps to Reproduce 1. Set up a NetBird network with: - Gateway node (`100.70.200.77`) routing to `100.70.169.36/32` and `100.70.47.126/32`. - ACLs for `gateway-users` group allowing TCP (443) and ICMP. 2. Connect **Linux (v0.43.1)** and **Android (v0.34.0)** clients. 3. On Linux: Check routes (`ip r`), ping gateway and resources. 4. On Android (via ADB): Check routes (`ip route`), ping gateway and resources. 5. On gateway: Run `tcpdump -ni wt0 icmp` during pings. ## Expected Behavior Android and Linux clients should ping `100.70.169.36` and `100.70.47.126` via the gateway, with `tcpdump` showing ICMP packets for all pings. ## Actual Behavior - **Linux**: - Route: `100.70.0.0/16` via `wt0`. - Pings to `100.70.200.77`, `100.70.169.36`, `100.70.47.126` succeed. - `tcpdump` shows all ICMP packets. - **Android**: - Route: `100.70.0.0/16` via `tun0`. - Ping to `100.70.200.77` succeeds; pings to `100.70.169.36`, `100.70.47.126` fail (100% packet loss). - `tcpdump` shows ICMP packets only for `100.70.200.77`. ## Environment - **NetBird Management**: v0.43.1 - **Netbird Linux client on Gateway node**: v0.43.1 - **Netbird Linux client on Desktop node**: v0.43.1 - **Android Netbird Client**: v0.34.0 - **Android version**: Android 15 (Xiaomi 14) ![Image](https://github.com/user-attachments/assets/e4f27d4d-e12d-4b77-bab9-ec2ea320fe1c) ![Image](https://github.com/user-attachments/assets/ce192abe-6fb4-43fd-b8a3-bfe2c4c191bc) ![Image](https://github.com/user-attachments/assets/9744499c-164d-4ea2-b9e9-c361b6efbc6d) ![Image](https://github.com/user-attachments/assets/93c983d5-7c84-4aa6-99c1-c04621c9871d) ## Diagnostics ### Linux Desktop Node Checking the availability of resources is successful ```bash % netbird version 0.43.1 % ip a show dev wt0 wt0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 100.70.222.106/16 brd 100.70.255.255 scope global wt0 valid_lft forever preferred_lft forever % ip r | grep 100.70 100.70.0.0/16 dev wt0 proto kernel scope link src 100.70.222.106 % wg interface: wt0 public key: OnYukdYUGEh5zqCttiXq6WICXoFLBbaSJeRotGlNJRE= private key: (hidden) listening port: 51820 fwmark: 0x1bd00 peer: ibJbTiGNdErXwhDwy+B7yN1n1MpdiacgJ7GYN9EXTHo= endpoint: 127.0.0.1:5 allowed ips: 100.70.47.126/32, 100.70.169.36/32, 100.70.200.77/32 latest handshake: 30 seconds ago transfer: 8.07 KiB received, 6.97 KiB sent persistent keepalive: every 25 seconds ## Successful ping to resource % ping -c 3 -I wt0 100.70.169.36 PING 100.70.169.36 (100.70.169.36) from 100.70.222.106 wt0: 56(84) bytes of data. 64 bytes from 100.70.169.36: icmp_seq=1 ttl=63 time=93.4 ms 64 bytes from 100.70.169.36: icmp_seq=2 ttl=63 time=91.3 ms 64 bytes from 100.70.169.36: icmp_seq=3 ttl=63 time=101 ms --- 100.70.169.36 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 91.253/95.112/100.635/4.006 ms % ping -c 3 -I wt0 100.70.169.36 PING 100.70.169.36 (100.70.169.36) from 100.70.222.106 wt0: 56(84) bytes of data. 64 bytes from 100.70.169.36: icmp_seq=1 ttl=63 time=93.2 ms 64 bytes from 100.70.169.36: icmp_seq=2 ttl=63 time=92.9 ms 64 bytes from 100.70.169.36: icmp_seq=3 ttl=63 time=96.2 ms --- 100.70.169.36 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 92.852/94.096/96.193/1.491 ms ``` ### Android (via ADB) Checking the availability of resources fails. ```bash % adb devices List of devices attached 45d66e71 device % adb shell ip a show dev tun0 tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500 link/none inet 100.70.10.225/16 scope global tun0 valid_lft forever preferred_lft forever % adb shell ip route 100.70.0.0/16 dev tun0 proto kernel scope link src 100.70.10.225 ## Successful ping to gateway % adb shell ping -c 3 -I tun0 100.70.200.77 PING 100.70.200.77 (100.70.200.77) from 100.70.10.225 tun0: 56(84) bytes of data. 64 bytes from 100.70.200.77: icmp_seq=1 ttl=64 time=72.2 ms 64 bytes from 100.70.200.77: icmp_seq=2 ttl=64 time=107 ms 64 bytes from 100.70.200.77: icmp_seq=3 ttl=64 time=29.4 ms --- 100.70.200.77 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 29.472/69.844/107.802/32.024 ms ## Failed ping to resource % adb shell ping -c 3 -I tun0 100.70.47.126 PING 100.70.47.126 (100.70.47.126) from 100.70.10.225 tun0: 56(84) bytes of data. --- 100.70.47.126 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2034ms ## Failed ping to resource % adb shell ping -c 3 -I tun0 100.70.169.36 PING 100.70.169.36 (100.70.169.36) from 100.70.10.225 tun0: 56(84) bytes of data. --- 100.70.169.36 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2040ms ``` ## Notes - Unable to run `wg show` on Android (no `wireguard-tools`). There is no way to check the `allowed ips` addresses on Android. ## Logs - Android: [netbird-1746115375059.log.txt](https://github.com/user-attachments/files/20001875/netbird-1746115375059.log.txt) or [pastebin](https://pastebin.com/raw/KSfTarSB)
Author
Owner

@atomlab commented on GitHub (May 2, 2025):

I downloaded the wg utility from the wireguard-tools package to an Android device for connection diagnostics.

# Download the package
wget https://packages.termux.dev/apt/termux-main/pool/main/w/wireguard-tools/wireguard-tools_1.0.20210914-2_aarch64.deb

# Extract the binary
ar x wireguard-tools_1.0.20210914-2_aarch64.deb

# Push the wg binary to the device
adb push data/data/com.termux/files/usr/bin/wg /data/local/tmp

Check version

adb shell /data/local/tmp/wg --version
# Output:
wireguard-tools v1.0.20210914 - https://git.zx2c4.com/wireguard-tools/

Show help

adb shell /data/local/tmp/wg --help

Lists all available subcommands (show, showconf, set, setconf, etc.)

Try to show peers

adb shell /data/local/tmp/wg show tun0

Unfortunately, SELinux security policies on Android prevent access to the interface when working via ADB :

Unable to access interface: Permission denied
@atomlab commented on GitHub (May 2, 2025): I downloaded the `wg` utility from the `wireguard-tools` package to an Android device for connection diagnostics. ```sh # Download the package wget https://packages.termux.dev/apt/termux-main/pool/main/w/wireguard-tools/wireguard-tools_1.0.20210914-2_aarch64.deb # Extract the binary ar x wireguard-tools_1.0.20210914-2_aarch64.deb # Push the wg binary to the device adb push data/data/com.termux/files/usr/bin/wg /data/local/tmp ``` ### Check version ```sh adb shell /data/local/tmp/wg --version # Output: wireguard-tools v1.0.20210914 - https://git.zx2c4.com/wireguard-tools/ ``` ### Show help ```sh adb shell /data/local/tmp/wg --help ``` Lists all available subcommands (`show`, `showconf`, `set`, `setconf`, etc.) ### Try to show peers ```sh adb shell /data/local/tmp/wg show tun0 ``` Unfortunately, SELinux security policies on Android prevent access to the interface when working via ADB : ``` Unable to access interface: Permission denied ```
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#334