[GH-ISSUE #5003] Impossible to ping Gl.iNet router #9680

Open
opened 2026-08-05 01:23:04 -04:00 by saavagebueno · 3 comments
Owner

Originally created by @BertrandCardot on GitHub (Dec 29, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5003

Hi,

I’m having an issue with a GL.iNet GL-AXT1800 router running OpenWrt + NetBird, and it looks like a backend / management problem on NetBird side.

Setup:

  • Peer 1 (router):

    • Device: GL.iNet GL-AXT1800 (OpenWrt)
    • NetBird CLI/Daemon version: 0.59.7 (linux/arm64, kernel interface)
    • FQDN: gl-axt1800.netbird.cloud
    • NetBird IP: 100.84.7.134/16
    • Networks: 192.168.8.0/24
    • Status: Management Connected, Signal Connected, 2/5 peers connected
  • Peer 2 (Mac):

    • Device: macOS arm64
    • NetBird version: 0.60.9 (userspace interface)
    • FQDN: air-de-bertrand.netbird.cloud
    • NetBird IP: 100.84.101.251/16
    • Status: Connected
  • Peer 3 (other client: Linux/Windows):

    • NetBird status: Connected
    • Can ping itself and can ping the Mac peer successfully

What works:

  • Peer 2 and Peer 3 can ping each other over NetBird.
  • Peers show up as Connected in the NetBird UI.
  • The router peer shows Network 192.168.8.0/24 correctly.

What does NOT work:

  • Neither Peer 2 nor Peer 3 can ping the router peer 100.84.7.134.
  • From Peer 2 (macOS), ping 100.84.7.134 → 100% packet loss.
  • From Peer 3 (Linux/Windows), ping 100.84.7.134 → 100% packet loss.
  • Sometimes, in the NetBird web UI, I get "Request failed with status code 500".

Access control:

  • I created a very permissive policy:
    • Source: All Peers
    • Destination: All Peers
    • Action: Allow
  • Even with this "allow all" policy, no peer can reach 100.84.7.134.

On the router side (OpenWrt):

  • Interface wt0 is up and attached to a netbird interface in /etc/config/network:
    • config interface 'netbird'
      option proto 'none'
      option device 'wt0'
  • Firewall zone:
    • zone 'netbird' with input/output/forward = ACCEPT and network 'netbird'
    • forwarding: lan -> netbird and netbird -> lan
  • netbird status on the router shows:
    • Management: Connected
    • Signal: Connected
    • NetBird IP: 100.84.7.134/16
    • Networks: 192.168.8.0/24
    • Peers count: 2/5 Connected

Given that:

  • peers can communicate between themselves (Mac <-> other client),
  • router peer is shown as Connected and announces 192.168.8.0/24,
  • but no one can reach the router peer (100.84.7.134),
  • and the UI sometimes returns HTTP 500,

it looks like there might be an issue on the NetBird management side for this peer/account (routing, policies, or backend error).

Could you please:

  • Check my account and the peer gl-axt1800.netbird.cloud (100.84.7.134),
  • See if there is any backend error, misconfiguration, or known issue that would prevent other peers from reaching this peer, even with an "allow all" policy,
  • And advise what I should change or if there is a bug on the server side?

Thanks in advance.

Originally created by @BertrandCardot on GitHub (Dec 29, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5003 Hi, I’m having an issue with a GL.iNet GL-AXT1800 router running OpenWrt + NetBird, and it looks like a backend / management problem on NetBird side. Setup: - Peer 1 (router): - Device: GL.iNet GL-AXT1800 (OpenWrt) - NetBird CLI/Daemon version: 0.59.7 (linux/arm64, kernel interface) - FQDN: gl-axt1800.netbird.cloud - NetBird IP: 100.84.7.134/16 - Networks: 192.168.8.0/24 - Status: Management Connected, Signal Connected, 2/5 peers connected - Peer 2 (Mac): - Device: macOS arm64 - NetBird version: 0.60.9 (userspace interface) - FQDN: air-de-bertrand.netbird.cloud - NetBird IP: 100.84.101.251/16 - Status: Connected - Peer 3 (other client: Linux/Windows): - NetBird status: Connected - Can ping itself and can ping the Mac peer successfully What works: - Peer 2 and Peer 3 can ping each other over NetBird. - Peers show up as Connected in the NetBird UI. - The router peer shows Network 192.168.8.0/24 correctly. What does NOT work: - Neither Peer 2 nor Peer 3 can ping the router peer 100.84.7.134. - From Peer 2 (macOS), ping 100.84.7.134 → 100% packet loss. - From Peer 3 (Linux/Windows), ping 100.84.7.134 → 100% packet loss. - Sometimes, in the NetBird web UI, I get "Request failed with status code 500". Access control: - I created a very permissive policy: - Source: All Peers - Destination: All Peers - Action: Allow - Even with this "allow all" policy, no peer can reach 100.84.7.134. On the router side (OpenWrt): - Interface wt0 is up and attached to a `netbird` interface in /etc/config/network: - config interface 'netbird' option proto 'none' option device 'wt0' - Firewall zone: - zone 'netbird' with input/output/forward = ACCEPT and `network 'netbird'` - forwarding: lan -> netbird and netbird -> lan - `netbird status` on the router shows: - Management: Connected - Signal: Connected - NetBird IP: 100.84.7.134/16 - Networks: 192.168.8.0/24 - Peers count: 2/5 Connected Given that: - peers can communicate between themselves (Mac <-> other client), - router peer is shown as Connected and announces 192.168.8.0/24, - but no one can reach the router peer (100.84.7.134), - and the UI sometimes returns HTTP 500, it looks like there might be an issue on the NetBird management side for this peer/account (routing, policies, or backend error). Could you please: - Check my account and the peer `gl-axt1800.netbird.cloud` (100.84.7.134), - See if there is any backend error, misconfiguration, or known issue that would prevent other peers from reaching this peer, even with an "allow all" policy, - And advise what I should change or if there is a bug on the server side? Thanks in advance.
saavagebueno added the triage-needed label 2026-08-05 01:23:04 -04:00
Author
Owner

@coderabbitai[bot] commented on GitHub (Dec 29, 2025):

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

  • Create Plan
Examples

🔗 Similar Issues

Possible Duplicates

Related Issues

👤 Suggested Assignees

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

<!-- gh-comment-id:3696667119 --> @coderabbitai[bot] commented on GitHub (Dec 29, 2025): <!-- This is an auto-generated issue plan by CodeRabbit --> ### 📝 CodeRabbit Plan Mode Generate an implementation plan and prompts that you can use with your favorite coding agent. - [ ] <!-- {"checkboxId": "8d4f2b9c-3e1a-4f7c-a9b2-d5e8f1c4a7b9"} --> Create Plan <details> <summary>Examples</summary> - [Example 1](https://github.com/coderabbitai/git-worktree-runner/issues/29#issuecomment-3589134556) - [Example 2](https://github.com/coderabbitai/git-worktree-runner/issues/12#issuecomment-3606665167) </details> --- <details> <summary><b>🔗 Similar Issues</b></summary> **Possible Duplicates** - https://github.com/netbirdio/netbird/issues/4991 **Related Issues** - https://github.com/netbirdio/netbird/issues/3828 - https://github.com/netbirdio/netbird/issues/4765 - https://github.com/netbirdio/netbird/issues/4913 </details> <details> <summary><b>👤 Suggested Assignees</b></summary> - [raaron773](https://github.com/raaron773) - [luantran96](https://github.com/luantran96) - [mitchplze](https://github.com/mitchplze) - [reddwarf666](https://github.com/reddwarf666) </details> --- <details> <summary> 🧪 Issue enrichment is currently in open beta.</summary> You can configure auto-planning by selecting labels in the issue_enrichment configuration. To disable automatic issue enrichment, add the following to your `.coderabbit.yaml`: ```yaml issue_enrichment: auto_enrich: enabled: false ``` </details> 💬 Have feedback or questions? Drop into our [discord](https://discord.gg/coderabbit)!
Author
Owner

@BertrandCardot commented on GitHub (Dec 29, 2025):

Hi,

I’m having an issue with a GL.iNet GL-AXT1800 router running OpenWrt + NetBird, and it looks like a backend / management problem on NetBird side.

Setup:

  • Peer 1 (router):

    • Device: GL.iNet GL-AXT1800 (OpenWrt)
    • NetBird CLI/Daemon version: 0.59.7 (linux/arm64, kernel interface)
    • FQDN: gl-axt1800.netbird.cloud
    • NetBird IP: 100.84.7.134/16
    • Networks: 192.168.8.0/24
    • Status: Management Connected, Signal Connected, 2/5 peers connected
  • Peer 2 (Mac):

    • Device: macOS arm64
    • NetBird version: 0.60.9 (userspace interface)
    • FQDN: air-de-bertrand.netbird.cloud
    • NetBird IP: 100.84.101.251/16
    • Status: Connected
  • Peer 3 (other client: Linux/Windows):

    • NetBird status: Connected
    • Can ping itself and can ping the Mac peer successfully

What works:

  • Peer 2 and Peer 3 can ping each other over NetBird.
  • Peers show up as Connected in the NetBird UI.
  • The router peer shows Network 192.168.8.0/24 correctly.

What does NOT work:

  • Neither Peer 2 nor Peer 3 can ping the router peer 100.84.7.134.
  • From Peer 2 (macOS), ping 100.84.7.134 → 100% packet loss.
  • From Peer 3 (Linux/Windows), ping 100.84.7.134 → 100% packet loss.
  • Sometimes, in the NetBird web UI, I get "Request failed with status code 500".

Access control:

  • I created a very permissive policy:
    • Source: All Peers
    • Destination: All Peers
    • Action: Allow
  • Even with this "allow all" policy, no peer can reach 100.84.7.134.

On the router side (OpenWrt):

  • Interface wt0 is up and attached to a netbird interface in /etc/config/network:
    • config interface 'netbird'
      option proto 'none'
      option device 'wt0'
  • Firewall zone:
    • zone 'netbird' with input/output/forward = ACCEPT and network 'netbird'
    • forwarding: lan -> netbird and netbird -> lan
  • netbird status on the router shows:
    • Management: Connected
    • Signal: Connected
    • NetBird IP: 100.84.7.134/16
    • Networks: 192.168.8.0/24
    • Peers count: 2/5 Connected

Given that:

  • peers can communicate between themselves (Mac <-> other client),
  • router peer is shown as Connected and announces 192.168.8.0/24,
  • but no one can reach the router peer (100.84.7.134),
  • and the UI sometimes returns HTTP 500,

it looks like there might be an issue on the NetBird management side for this peer/account (routing, policies, or backend error).

Could you please:

  • Check my account and the peer gl-axt1800.netbird.cloud (100.84.7.134),
  • See if there is any backend error, misconfiguration, or known issue that would prevent other peers from reaching this peer, even with an "allow all" policy,
  • And advise what I should change or if there is a bug on the server side?

Thanks in advance.

<!-- gh-comment-id:3697053752 --> @BertrandCardot commented on GitHub (Dec 29, 2025): Hi, I’m having an issue with a GL.iNet GL-AXT1800 router running OpenWrt + NetBird, and it looks like a backend / management problem on NetBird side. Setup: - Peer 1 (router): - Device: GL.iNet GL-AXT1800 (OpenWrt) - NetBird CLI/Daemon version: 0.59.7 (linux/arm64, kernel interface) - FQDN: gl-axt1800.netbird.cloud - NetBird IP: 100.84.7.134/16 - Networks: 192.168.8.0/24 - Status: Management Connected, Signal Connected, 2/5 peers connected - Peer 2 (Mac): - Device: macOS arm64 - NetBird version: 0.60.9 (userspace interface) - FQDN: air-de-bertrand.netbird.cloud - NetBird IP: 100.84.101.251/16 - Status: Connected - Peer 3 (other client: Linux/Windows): - NetBird status: Connected - Can ping itself and can ping the Mac peer successfully What works: - Peer 2 and Peer 3 can ping each other over NetBird. - Peers show up as Connected in the NetBird UI. - The router peer shows Network 192.168.8.0/24 correctly. What does NOT work: - Neither Peer 2 nor Peer 3 can ping the router peer 100.84.7.134. - From Peer 2 (macOS), ping 100.84.7.134 → 100% packet loss. - From Peer 3 (Linux/Windows), ping 100.84.7.134 → 100% packet loss. - Sometimes, in the NetBird web UI, I get "Request failed with status code 500". Access control: - I created a very permissive policy: - Source: All Peers - Destination: All Peers - Action: Allow - Even with this "allow all" policy, no peer can reach 100.84.7.134. On the router side (OpenWrt): - Interface wt0 is up and attached to a `netbird` interface in /etc/config/network: - config interface 'netbird' option proto 'none' option device 'wt0' - Firewall zone: - zone 'netbird' with input/output/forward = ACCEPT and `network 'netbird'` - forwarding: lan -> netbird and netbird -> lan - `netbird status` on the router shows: - Management: Connected - Signal: Connected - NetBird IP: 100.84.7.134/16 - Networks: 192.168.8.0/24 - Peers count: 2/5 Connected Given that: - peers can communicate between themselves (Mac <-> other client), - router peer is shown as Connected and announces 192.168.8.0/24, - but no one can reach the router peer (100.84.7.134), - and the UI sometimes returns HTTP 500, it looks like there might be an issue on the NetBird management side for this peer/account (routing, policies, or backend error). Could you please: - Check my account and the peer `gl-axt1800.netbird.cloud` (100.84.7.134), - See if there is any backend error, misconfiguration, or known issue that would prevent other peers from reaching this peer, even with an "allow all" policy, - And advise what I should change or if there is a bug on the server side? Thanks in advance.
Author
Owner

@DriedPlumber commented on GitHub (Dec 31, 2025):

Hi, adding another datapoint that looks GL.iNet firmware / OpenWrt-overlay related rather than a NetBird core issue.

Environment

NetBird: self-hosted (not NetBird Cloud)

I have multiple other remote locations/networks on the same self-hosted instance and they work without issues (routing + access).

Because other sites work fine, suspicion points to GL.iNet’s OpenWrt-derived firmware layer (firewall/forwarding/offloading/rp_filter quirks), not NetBird backend.

Setup (problem site)

Router: GL.iNet GL-X2000 (GL.iNet firmware / OpenWrt-derived “overlay”)

LAN: 192.168.20.0/24, GW 192.168.20.1

Routing peer behind the router: Home Assistant OS host 192.168.20.178 with NetBird add-on v0.60.8

Advertised route: 192.168.20.0/24

Masquerade: ON

Remote peers: Windows/macOS/etc (other sites on same self-hosted NetBird)

What works

From remote peers over NetBird I can reach Home Assistant itself:

ping 192.168.20.178 works

http://192.168.20.178:8123 works

From HA locally (SSH): HA can ping any LAN device (192.168.20.1, 192.168.20.100, …).

When I connect physically to local Wi-Fi/LAN, everything works immediately (LAN is healthy).

What does NOT work

From remote peers over NetBird I cannot reach any other LAN device behind the GL-X2000:

ping 192.168.20.1 / ping 192.168.20.100 → 100% loss

Windows remote peer has the route installed as expected, e.g.:

192.168.20.0/24 -> On-link via NetBird interface (100.101.x.x)

So traffic is sent into NetBird, but forwarded traffic (NetBird → HA routing peer → LAN) never succeeds, except for the HA host itself.

Why I suspect GL.iNet overlay / return-path behavior

Same style of setup works fine on my other sites.

I also have a similar configuration working on vanilla OpenWrt.

On GL.iNet firmware, the symptoms match a return-path / forwarding / offloading / rp_filter issue: HA can reach LAN, but forwarded overlay traffic does not come back.

Potential workaround / next steps

A likely workaround is to avoid relying on masquerade and instead add a static route on the GL.iNet router for the NetBird CGNAT range back to the routing peer, e.g.:

100.64.0.0/10 via 192.168.20.178 (or narrower 100.101.0.0/16 in my case) — I still need to test this.

If maintainers have specific debugging steps they want (tcpdump on wt0 vs LAN, iptables/nft counters, rp_filter values, flow offloading), I can provide outputs.

Note: This might be specific to GL-X2000 because it can’t easily run vanilla OpenWrt (LTE modem/Qualcomm driver constraints), so the “overlay” firmware behavior may be hard to avoid on this model.

<!-- gh-comment-id:3701822974 --> @DriedPlumber commented on GitHub (Dec 31, 2025): Hi, adding another datapoint that looks GL.iNet firmware / OpenWrt-overlay related rather than a NetBird core issue. Environment NetBird: self-hosted (not NetBird Cloud) I have multiple other remote locations/networks on the same self-hosted instance and they work without issues (routing + access). Because other sites work fine, suspicion points to GL.iNet’s OpenWrt-derived firmware layer (firewall/forwarding/offloading/rp_filter quirks), not NetBird backend. Setup (problem site) Router: GL.iNet GL-X2000 (GL.iNet firmware / OpenWrt-derived “overlay”) LAN: 192.168.20.0/24, GW 192.168.20.1 Routing peer behind the router: Home Assistant OS host 192.168.20.178 with NetBird add-on v0.60.8 Advertised route: 192.168.20.0/24 Masquerade: ON Remote peers: Windows/macOS/etc (other sites on same self-hosted NetBird) What works From remote peers over NetBird I can reach Home Assistant itself: ping 192.168.20.178 works http://192.168.20.178:8123 works From HA locally (SSH): HA can ping any LAN device (192.168.20.1, 192.168.20.100, …). When I connect physically to local Wi-Fi/LAN, everything works immediately (LAN is healthy). What does NOT work From remote peers over NetBird I cannot reach any other LAN device behind the GL-X2000: ping 192.168.20.1 / ping 192.168.20.100 → 100% loss Windows remote peer has the route installed as expected, e.g.: 192.168.20.0/24 -> On-link via NetBird interface (100.101.x.x) So traffic is sent into NetBird, but forwarded traffic (NetBird → HA routing peer → LAN) never succeeds, except for the HA host itself. Why I suspect GL.iNet overlay / return-path behavior Same style of setup works fine on my other sites. I also have a similar configuration working on vanilla OpenWrt. On GL.iNet firmware, the symptoms match a return-path / forwarding / offloading / rp_filter issue: HA can reach LAN, but forwarded overlay traffic does not come back. Potential workaround / next steps A likely workaround is to avoid relying on masquerade and instead add a static route on the GL.iNet router for the NetBird CGNAT range back to the routing peer, e.g.: 100.64.0.0/10 via 192.168.20.178 (or narrower 100.101.0.0/16 in my case) — I still need to test this. If maintainers have specific debugging steps they want (tcpdump on wt0 vs LAN, iptables/nft counters, rp_filter values, flow offloading), I can provide outputs. Note: This might be specific to GL-X2000 because it can’t easily run vanilla OpenWrt (LTE modem/Qualcomm driver constraints), so the “overlay” firmware behavior may be hard to avoid on this model.
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#9680