[GH-ISSUE #4657] Bug: iOS Client loses all routes when Posture Checks are enabled #9953

Closed
opened 2026-08-05 01:24:07 -04:00 by saavagebueno · 5 comments
Owner

Originally created by @Miki84 on GitHub (Oct 17, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4657

Description
When using Posture Checks to prevent routing conflicts in home networks, the iOS client loses all routes and becomes non-functional, while the Windows client works as expected.

Current Behavior

Windows Client: Posture Checks work correctly - routes are properly managed based on network detection
iOS Client: All routes disappear when Posture Checks are enabled, regardless of which network the device is connected to

Steps to Reproduce

Set up self-hosted Netbird with "Connect on Startup" enabled
Configure Posture Check to block peer network range 192.168.1.0/24
Connect iOS client to Netbird
Observe that all routes disappear from the iOS client

Expected Behavior
The iOS client should handle Posture Checks the same way as the Windows client:

Routes should be dynamically managed based on the current network environment
When NOT in the blocked network range (e.g., at work), routes should be established normally
When IN the blocked network range (e.g., at home on 192.168.1.0/24), specific routes should be blocked to prevent routing conflicts

Context/Use Case
Problem being solved:
When at home, the Netbird connection takes priority over the local LAN/WiFi connection due to lower routing metrics. This causes traffic to home network devices (192.168.1.0/24) to be routed through the Netbird tunnel instead of using the direct local connection, which is inefficient and causes connectivity issues.
Workaround strategy:
Using Posture Checks to block the peer network range 192.168.1.0/24 prevents this routing conflict by detecting when the client is on the home network and adjusting routes accordingly.
Environment

Netbird Version Windows: 0.59.6
Netbird Version iOS: 0.55.1
Deployment: Self-hosted
Affected Platform: iOS
Working Platform: Windows
Network Configuration:

Home network: 192.168.1.0/24
Posture Check: Blocking peer network range 192.168.1.0/24

Impact
This makes the iOS client unusable when Posture Checks are required, forcing users to either:

Disable Posture Checks (resulting in routing conflicts at home)
Manually disable/enable VPN connection (defeats the purpose of "Connect on Startup")

Additional Information
The same Posture Check configuration works perfectly on Windows, suggesting this is an iOS-specific implementation issue with how routes are handled when Posture Checks are active.

Originally created by @Miki84 on GitHub (Oct 17, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4657 Description When using Posture Checks to prevent routing conflicts in home networks, the iOS client loses all routes and becomes non-functional, while the Windows client works as expected. Current Behavior Windows Client: Posture Checks work correctly - routes are properly managed based on network detection iOS Client: All routes disappear when Posture Checks are enabled, regardless of which network the device is connected to Steps to Reproduce Set up self-hosted Netbird with "Connect on Startup" enabled Configure Posture Check to block peer network range 192.168.1.0/24 Connect iOS client to Netbird Observe that all routes disappear from the iOS client Expected Behavior The iOS client should handle Posture Checks the same way as the Windows client: Routes should be dynamically managed based on the current network environment When NOT in the blocked network range (e.g., at work), routes should be established normally When IN the blocked network range (e.g., at home on 192.168.1.0/24), specific routes should be blocked to prevent routing conflicts Context/Use Case Problem being solved: When at home, the Netbird connection takes priority over the local LAN/WiFi connection due to lower routing metrics. This causes traffic to home network devices (192.168.1.0/24) to be routed through the Netbird tunnel instead of using the direct local connection, which is inefficient and causes connectivity issues. Workaround strategy: Using Posture Checks to block the peer network range 192.168.1.0/24 prevents this routing conflict by detecting when the client is on the home network and adjusting routes accordingly. Environment Netbird Version Windows: 0.59.6 Netbird Version iOS: 0.55.1 Deployment: Self-hosted Affected Platform: iOS Working Platform: Windows Network Configuration: Home network: 192.168.1.0/24 Posture Check: Blocking peer network range 192.168.1.0/24 Impact This makes the iOS client unusable when Posture Checks are required, forcing users to either: Disable Posture Checks (resulting in routing conflicts at home) Manually disable/enable VPN connection (defeats the purpose of "Connect on Startup") Additional Information The same Posture Check configuration works perfectly on Windows, suggesting this is an iOS-specific implementation issue with how routes are handled when Posture Checks are active.
saavagebueno added the triage-needed label 2026-08-05 01:24:07 -04:00
Author
Owner

@levindecaro commented on GitHub (Oct 27, 2025):

same here, any peer network range posture policy enforcement define in the network route will disable the route in iOS, however MacOS, Windows are working as expected.

Netbird Server version .0.59.6
Netbird iOS version: 0.0.11

<!-- gh-comment-id:3450220013 --> @levindecaro commented on GitHub (Oct 27, 2025): same here, any peer network range posture policy enforcement define in the network route will disable the route in iOS, however MacOS, Windows are working as expected. Netbird Server version .0.59.6 Netbird iOS version: 0.0.11
Author
Owner

@robotkid450 commented on GitHub (Nov 4, 2025):

This is also the case on Android.
Netbird Android version: 0.58.1

<!-- gh-comment-id:3488666159 --> @robotkid450 commented on GitHub (Nov 4, 2025): This is also the case on Android. Netbird Android version: 0.58.1
Author
Owner

@Tyraenor commented on GitHub (Nov 19, 2025):

Same here.

Server version: 0.60.1
iOS version: 0.59.5

<!-- gh-comment-id:3553620539 --> @Tyraenor commented on GitHub (Nov 19, 2025): Same here. Server version: 0.60.1 iOS version: 0.59.5
Author
Owner

@mlsmaycon commented on GitHub (Dec 16, 2025):

Hello Folks, iOS and Android clients don't support private network ranges posture checks. These operating systems don't allow fetching local IP information.

We have a few workarounds to work on and we will update you soon.

<!-- gh-comment-id:3659812282 --> @mlsmaycon commented on GitHub (Dec 16, 2025): Hello Folks, iOS and Android clients don't support private network ranges posture checks. These operating systems don't allow fetching local IP information. We have a few workarounds to work on and we will update you soon.
Author
Owner

@Miki84 commented on GitHub (Apr 28, 2026):

Hi team,

I'd like to reopen this issue. After the latest update, the fix works correctly for Network Routes — routes are no longer lost when Posture Checks are enabled. Thanks for addressing that!

However, the same problem still persists for Network Resources. When Posture Checks are active, the iOS client loses access to all configured network resources.

Since the root cause appears to be the same (posture check evaluation dropping route/resource entries on iOS), it would make sense to keep this issue open until both network routes and network resources are handled correctly.

Happy to provide logs or additional details if needed.

<!-- gh-comment-id:4333590611 --> @Miki84 commented on GitHub (Apr 28, 2026): Hi team, I'd like to reopen this issue. After the latest update, the fix works correctly for **Network Routes** — routes are no longer lost when Posture Checks are enabled. Thanks for addressing that! However, the same problem still persists for **Network Resources**. When Posture Checks are active, the iOS client loses access to all configured network resources. Since the root cause appears to be the same (posture check evaluation dropping route/resource entries on iOS), it would make sense to keep this issue open until both network routes and network resources are handled correctly. Happy to provide logs or additional details if needed.
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#9953