PMTU blackhole between macOS client and self-hosted NetBird-Only reverse-proxy peer causes stalls #6923
Unanswered
kurthw
asked this question in
Issue Triage
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Before posting
Affected area
Connectivity / Peer-to-peer (P2P) / MTU
Deployment type
Self-hosted - advanced/custom deployment
Operating system or environment
macOS
NetBird version and upgrade status
Did this work before?
Not sure
Regression details
N/A
Summary
When accessing a service behind a NetBird-Only access policy from a macOS client, larger payloads intermittently stall or fail while small requests succeed. Root cause traced to a PMTU blackhole on the path to the controlplane/reverse-proxy peer: packets exceeding the effective path MTU are silently dropped rather than triggering an ICMP "Fragmentation Needed" response, so the client's WireGuard interface never learns to reduce its packet size.
Current behavior
HTTPS requests to services behind the NetBird-Only policy intermittently stall or time out once payload size exceeds the effective path MTU. Small requests (e.g. simple API calls) succeed normally. No error is surfaced to the user beyond the stall/timeout itself.
Expected behavior
The client should perform automatic PMTU discovery/adjustment for the WireGuard interface, or at minimum surface a diagnostic/warning when a PMTU blackhole is detected, so users don't have to manually discover and set a lower MTU via
netbird up --mtu <value>.Steps to reproduce
netbird up --mtu 1150) — issue disappears completelyEnvironment and topology
Self-hosted details, if available
Logs, status output, or debug evidence
Related issues or discussions
N/A — not found in existing search
Impact
netbird up --mtu 1150Additional context
No response
All reactions