[GH-ISSUE #5811] Feature Request: Expose per-peer LAN IP address in management API (GET /api/peers or GET /api/routes) #12023

Open
opened 2026-08-05 01:32:09 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @renne on GitHub (Apr 7, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5811

When a NetBird peer acts as a subnet router (routing peer), it has both an overlay mesh IP (100.x.x.x, returned as ip in GET /api/peers) and a physical LAN IP on the network it routes for.
External systems that need to use the routing peer as a next-hop gateway — such as local gateway routers that receive statically injected routes — can only obtain the LAN IP today through manual configuration, because the management API does not expose it.

Concrete example: a sidecar daemon (netbird-tr064) runs alongside a NetBird client and syncs NetBird-advertised subnets into a Fritz!Box router's routing table via TR-064. It needs to set a NextHopGateway for each injected route. That gateway is the LAN IP of the routing peer — information the management API cannot currently provide.

Today the workaround is a static peers map in the sidecar's config.yaml:

routers:
  - host: fritz.box
    peers:
      "<peer-id>": "192.168.1.50"   # LAN IP — must be set manually

This is error-prone, not self-healing, and cannot be automated.


Describe the solution you'd like

Extend the management API to include the physical LAN IP address(es) of each peer that acts as a subnet router.

Option A – Extend GET /api/peers response

Add a field (e.g. lan_ips or network_interfaces) to the existing peer object:

{
  "id": "chacgt2btg...",
  "name": "router-home",
  "ip": "100.68.0.1",           // existing: overlay mesh IP
  "connection_ip": "1.2.3.4",   // existing: WAN/public IP
  "lan_ips": ["192.168.1.50"]   // NEW: physical LAN interface IPs
}

The NetBird agent already knows its own LAN interface IPs at runtime (it uses them for peer-to-peer connection establishment). The agent could report them to the management server during handshake/heartbeat, and the management server would expose them via the API.

Option B – Include next-hop gateway in GET /api/routes

Since routes already carry peer (routing peer ID) and network (CIDR), also add a gateway field that resolves to the routing peer's LAN IP:

{
  "id": "route-abc",
  "network": "192.168.1.0/24",
  "peer": "chacgt2btg...",
  "gateway": "192.168.1.50"     // NEW: LAN IP of the routing peer on the advertised network
}

This is more useful for route-injection use cases, since the consumer gets a fully resolved next-hop without joining data across two endpoints.

Either option (or both) would allow external systems to discover subnet-router LAN IPs without manual configuration.


Describe alternatives you've considered

  • Fritz!Box Hosts:1 DHCP lookup: query the router's own DHCP table to map the peer's hostname to a LAN IP. Rejected — this couples external tooling to AVM-specific APIs and only works if the peer has a DHCP lease on that router. It is a workaround for a missing upstream feature.
  • Static configuration (current state): maintain a peer_id → LAN IP map in an external config file. Works, but requires manual updates whenever peers change and cannot support automated failover.
  • connection_ip field in GET /api/peers: this already exists but returns the WAN/public IP of the peer, not its LAN IP.

Additional context

  • Related: #5801 — a broader request for management-server-driven TR-064 route injection; exposing LAN IPs is a prerequisite for that integration working without manual configuration.
  • The netbird-tr064 sidecar daemon currently tracks this gap with a TODO comment in its source.
  • The NetBird agent already gathers local interface information during WireGuard setup; reporting those IPs to the management server should be a contained change.
Originally created by @renne on GitHub (Apr 7, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5811 ### Is your feature request related to a problem? When a NetBird peer acts as a **subnet router** (routing peer), it has both an overlay mesh IP (`100.x.x.x`, returned as `ip` in `GET /api/peers`) and a **physical LAN IP** on the network it routes for. External systems that need to use the routing peer as a **next-hop gateway** — such as local gateway routers that receive statically injected routes — can only obtain the LAN IP today through manual configuration, because the management API does not expose it. Concrete example: a sidecar daemon ([netbird-tr064](https://github.com/renne/netbird-tr064)) runs alongside a NetBird client and syncs NetBird-advertised subnets into a Fritz!Box router's routing table via TR-064. It needs to set a `NextHopGateway` for each injected route. That gateway is the LAN IP of the routing peer — information the management API cannot currently provide. Today the workaround is a static `peers` map in the sidecar's `config.yaml`: ```yaml routers: - host: fritz.box peers: "<peer-id>": "192.168.1.50" # LAN IP — must be set manually ``` This is error-prone, not self-healing, and cannot be automated. --- ### Describe the solution you'd like Extend the management API to include the physical LAN IP address(es) of each peer that acts as a subnet router. **Option A – Extend `GET /api/peers` response** Add a field (e.g. `lan_ips` or `network_interfaces`) to the existing peer object: ```jsonc { "id": "chacgt2btg...", "name": "router-home", "ip": "100.68.0.1", // existing: overlay mesh IP "connection_ip": "1.2.3.4", // existing: WAN/public IP "lan_ips": ["192.168.1.50"] // NEW: physical LAN interface IPs } ``` The NetBird agent already knows its own LAN interface IPs at runtime (it uses them for peer-to-peer connection establishment). The agent could report them to the management server during handshake/heartbeat, and the management server would expose them via the API. **Option B – Include next-hop gateway in `GET /api/routes`** Since routes already carry `peer` (routing peer ID) and `network` (CIDR), also add a `gateway` field that resolves to the routing peer's LAN IP: ```jsonc { "id": "route-abc", "network": "192.168.1.0/24", "peer": "chacgt2btg...", "gateway": "192.168.1.50" // NEW: LAN IP of the routing peer on the advertised network } ``` This is more useful for route-injection use cases, since the consumer gets a fully resolved next-hop without joining data across two endpoints. Either option (or both) would allow external systems to discover subnet-router LAN IPs without manual configuration. --- ### Describe alternatives you've considered - **Fritz!Box `Hosts:1` DHCP lookup**: query the router's own DHCP table to map the peer's hostname to a LAN IP. Rejected — this couples external tooling to AVM-specific APIs and only works if the peer has a DHCP lease on that router. It is a workaround for a missing upstream feature. - **Static configuration** (current state): maintain a `peer_id → LAN IP` map in an external config file. Works, but requires manual updates whenever peers change and cannot support automated failover. - **`connection_ip` field in `GET /api/peers`**: this already exists but returns the WAN/public IP of the peer, not its LAN IP. --- ### Additional context - Related: #5801 — a broader request for management-server-driven TR-064 route injection; exposing LAN IPs is a prerequisite for that integration working without manual configuration. - The [netbird-tr064](https://github.com/renne/netbird-tr064) sidecar daemon currently tracks this gap with a `TODO` comment in its source. - The NetBird agent already gathers local interface information during WireGuard setup; reporting those IPs to the management server should be a contained change.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#12023