search

netbirdio / netbird

Connect your devices into a secure WireGuard®-based overlay network with SSO, MFA and granular access controls.
https://netbird.io
BSD 3-Clause "New" or "Revised" License
11.2k stars 517 forks source link

Route handling regression: HTTP traffic fails on LAN IPs while other protocols work #2903

Open cipherw0lf opened 4 hours ago

cipherw0lf commented 4 hours ago

Describe the problem

HTTP/HTTPS traffic fails when accessing a NetBird client using its LAN IP address, despite routes being correctly configured. This issue appeared after a recent NetBird update and has been reproduced in two independent environments.

Current Behavior

  1. HTTP/HTTPS Traffic:

    • Fails/times out when accessing LAN IP (192.168.20.23)
    • Works perfectly when using NetBird IP (100.90.x.x)
    • Other HTTP resources on same subnet (e.g., 192.168.20.8) work fine

  2. Other Protocols:

    • SSH (tcp/22) to 192.168.20.23 works correctly
    • iperf3 (tcp/5201) to 192.168.20.23 works correctly (correct throughput)
    • Only HTTP/HTTPS traffic is affected

To Reproduce

Steps to reproduce the behavior:

  1. Configure NetBird client on LAN (192.168.20.23/24)
  2. Add route for 192.168.20.0/24 in NetBird dashboard

  3. From another NetBird client, attempt to access:

    # These fail
curl http://192.168.20.23
curl https://192.168.20.23
curl http://192.168.20.23:81
curl https://192.168.20.23:9443

# These work
ssh user@192.168.20.23
curl http://100.90.x.x    # NetBird IP of same host
curl http://192.168.20.100 (Different host on same LAN)

Expected behavior

Are you using NetBird Cloud?

No. Self hosted using getting-started-with-zitadel.sh script

NetBird version

Client node version

OS: darwin/amd64 Daemon version: 0.32.0 CLI version: 0.32.0 Management: Connected to https://netbird.anon-PDpeG.domain:443 Signal: Connected to https://netbird.anon-PDpeG.domain:443 Relays: [stun:netbird.anon-PDpeG.domain:3478] is Available [turn:netbird.anon-PDpeG.domain:3478?transport=udp] is Available Nameservers: [192.168.0.8:53, 192.168.0.9:53] for [anon-H9yIg.domain] is Available [192.168.40.3:53, 192.168.40.7:53] for [anon-sVKwC.domain] is Available [192.168.20.8:53, 192.168.30.4:53] for [anon-wHSfX.domain] is Available FQDN: rm-mbp.netbird.selfhosted NetBird IP: 100.90.44.172/16 Interface type: Userspace Quantum resistance: false Routes: - Peers count: 8/9 Connected

Node with route host

OS: linux/amd64 Daemon version: 0.32.0 CLI version: 0.32.0 Management: Connected to https://netbird.anon-glhvW.domain:443 Signal: Connected to https://netbird.anon-glhvW.domain:443 Relays: [stun:netbird.anon-glhvW.domain:3478] is Available [turn:netbird.anon-glhvW.domain:3478?transport=udp] is Available Nameservers: FQDN: selby-ubuntu-docker.netbird.selfhosted NetBird IP: 100.90.109.225/16 Interface type: Kernel Quantum resistance: false Routes: 192.168.20.0/24 Peers count: 8/9 Connected

cipherw0lf commented 3 hours ago

I have narrowed the issue down to docker containers' exposed services. These netbird peers are installed on docker hosts. However the containers' exposed ports are bound to all interfaces (0.0.0.0) and this has worked fine for 4 months since deployment of netbird.

lixmal commented 2 hours ago

Hi @cipherw0lf, what does your access policy look like? if you have specific ports there you might need to add the listening port in the container, additionally to the exposed port