[GH-ISSUE #5308] pkgs.netbird.io unreachable on BayernWLAN (TLS handshake hangs only when SNI=pkgs.netbird.io) #10961

Closed
opened 2026-08-05 01:27:52 -04:00 by saavagebueno · 2 comments
Owner

Originally created by @geigerl on GitHub (Feb 13, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5308

Describe the problem

On a Raspberry Pi 5 connected to the public BayernWLAN hotspot, I can’t reach NetBird’s package server pkgs.netbird.io over HTTPS. The TCP connection to port 443 succeeds, but the TLS handshake hangs right after the ClientHello only when SNI is set to pkgs.netbird.io.

If I connect without SNI (or connect to the IP directly), TLS works and I can fetch content. This prevents installing/updating NetBird via the Debian/apt repository described in the Linux install docs.

BayernWLAN is advertised as having a “Jugendschutzfilter” (youth/teen protection filter), so this may be caused by hotspot filtering based on TLS SNI. Talking with the hotline of the hotspot provider did not help.

The problem did not exist before Wednesday Febraury 11th 2026 (so 2 days ago). I don't know whether this is caused by the hotspot network or netbird infrastructure. I am sorry in advance if the problem is on our side...
BTW is this normal, that pkgs.netbird.io cannot be pinged via IPv4 (even from a network where pkgs.netbird.io is for sure reachable and TLS is working)?

  • ping -v -4 -c 3 -W 10 pkgs.netbird.io
ping: sock4.fd: 3 (socktype: SOCK_RAW), sock6.fd: -1 (socktype: 0), hints.ai_family: AF_INET

ai->ai_family: AF_INET6, ai->ai_canonname: 'pkgs.netbird.io'
ai->ai_family: AF_INET, ai->ai_canonname: ''
PING pkgs.netbird.io (5.22.212.152) 56(84) bytes of data.

--- pkgs.netbird.io ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2047ms
  • whereas with IPv6 it works ping -v -6 -c 3 -W 10 pkgs.netbird.io
ping: sock4.fd: -1 (socktype: 0), sock6.fd: 3 (socktype: SOCK_RAW), hints.ai_family: AF_INET6

ai->ai_family: AF_INET6, ai->ai_canonname: 'pkgs.netbird.io'
PING pkgs.netbird.io (2a04:3542:1000:910:2465:1fff:fe8a:1d97) 56 data bytes
64 bytes from pkgs.netbird.io (2a04:3542:1000:910:2465:1fff:fe8a:1d97): icmp_seq=1 ident=57083 ttl=54 time=18.4 ms
64 bytes from pkgs.netbird.io (2a04:3542:1000:910:2465:1fff:fe8a:1d97): icmp_seq=2 ident=57083 ttl=54 time=13.1 ms
64 bytes from pkgs.netbird.io (2a04:3542:1000:910:2465:1fff:fe8a:1d97): icmp_seq=3 ident=57083 ttl=54 time=13.4 ms

--- pkgs.netbird.io ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 13.061/14.948/18.368/2.422 ms

To Reproduce

  1. Connect a Raspberry Pi 5 to BayernWLAN (public Wi-Fi hotspot). IPv6 is not available on this network.
  2. Try accessing the package repo:
    • curl -4 -v https://pkgs.netbird.io/
  3. Observe it hangs after:
    • TLS handshake, Client hello
*   Trying 5.22.212.152:443...
* Connected to pkgs.netbird.io (5.22.212.152) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs

Additional tests show SNI-specific blocking:

  • With SNI (hangs):

    • printf 'GET / HTTP/1.1\r\nHost: pkgs.netbird.io\r\nConnection: close\r\n\r\n' | openssl s_client -connect 5.22.212.152:443 -servername pkgs.netbird.io -quiet
    • result: hangs
  • Without SNI (TLS works):

    • printf 'GET / HTTP/1.1\r\nHost: pkgs.netbird.io\r\nConnection: close\r\n\r\n' | openssl s_client -connect 5.22.212.152:443 -noservername -quiet
    • result:
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R13
verify return:1
depth=0 CN = pkgs.netbird.io
verify return:1
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 13 Feb 2026 13:51:23 GMT
Content-Type: application/octet-stream
Content-Length: 2
Connection: close
Content-Type: text/plain
  • Connect by IP + set HTTP Host header (works):
    • curl -4vk https://5.22.212.152/ -H 'Host: pkgs.netbird.io'
    • Result: HTTP/1.1 200 OK

Connectivity check:

  • curl -I http://connectivitycheck.gstatic.com/generate_204 returns HTTP/1.1 204 No Content

Expected behavior

https://pkgs.netbird.io should be reachable from typical public Wi-Fi networks, or there should be an officially documented fallback installation/update path that does not depend on SNI to pkgs.netbird.io (e.g., a mirror hostname, or guidance to use an alternative distribution method).

Are you using NetBird Cloud?

yes

NetBird version

N/A – cannot install the client because the apt repo host pkgs.netbird.io is unreachable on this network.

Is any other VPN software installed?

Yes: Tailscale (only way atm accessing the Pi).

Debug output

Not available (NetBird client not installed yet).

Screenshots

N/A

Additional context

This looks like TLS SNI filtering on the hotspot: the connection only fails when the ClientHello contains SNI = pkgs.netbird.io. SNI is the TLS extension used to indicate the hostname during the handshake.

  • cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
  • uname -a
6.6.78-v8-16k
  • curl --version
curl 7.88.1 (aarch64-unknown-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.18 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u14
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
  • openssl version -a
OpenSSL 3.0.18 30 Sep 2025 (Library: OpenSSL 3.0.18 30 Sep 2025)
built on: Mon Feb  2 14:45:25 2026 UTC
platform: debian-arm64
options:  bn(64,64)
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-hoDPI0/openssl-3.0.18=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/aarch64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/aarch64-linux-gnu/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_armcap=0xbd
  • tailscale version
1.94.1
  tailscale commit: 62c6f1cd7560763edcc552251abadf7dd4659f82
  long version: 1.94.1-t62c6f1cd7-g09fea6572
  other commit: 09fea6572e9c7a839b4a8c209420141fdb33fbb4
  go version: go1.25.5
  • ca-certificates are "up-to-date", latest in apt repo apt list --installed | grep ca-cert -> ca-certificates/oldstable,oldstable,oldstable-updates,oldstable-updates,now 20230311+deb12u1 all [installed]

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (docs: https://docs.netbird.io/how-to/troubleshooting-client)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @geigerl on GitHub (Feb 13, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5308 **Describe the problem** On a Raspberry Pi 5 connected to the public **BayernWLAN** hotspot, I can’t reach NetBird’s package server `pkgs.netbird.io` over HTTPS. The TCP connection to port 443 succeeds, but the TLS handshake hangs right after the ClientHello **only when SNI is set to `pkgs.netbird.io`**. If I connect without SNI (or connect to the IP directly), TLS works and I can fetch content. This prevents installing/updating NetBird via the Debian/apt repository described in the Linux install docs. BayernWLAN is advertised as having a “Jugendschutzfilter” (youth/teen protection filter), so this may be caused by hotspot filtering based on TLS SNI. Talking with the hotline of the hotspot provider did not help. The problem did not exist before Wednesday Febraury 11th 2026 (so 2 days ago). I don't know whether this is caused by the hotspot network or netbird infrastructure. I am sorry in advance if the problem is on our side... BTW is this normal, that pkgs.netbird.io cannot be pinged via IPv4 (even from a network where pkgs.netbird.io is for sure reachable and TLS is working)? - `ping -v -4 -c 3 -W 10 pkgs.netbird.io ` ``` ping: sock4.fd: 3 (socktype: SOCK_RAW), sock6.fd: -1 (socktype: 0), hints.ai_family: AF_INET ai->ai_family: AF_INET6, ai->ai_canonname: 'pkgs.netbird.io' ai->ai_family: AF_INET, ai->ai_canonname: '' PING pkgs.netbird.io (5.22.212.152) 56(84) bytes of data. --- pkgs.netbird.io ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2047ms ``` - whereas with IPv6 it works `ping -v -6 -c 3 -W 10 pkgs.netbird.io ` ``` ping: sock4.fd: -1 (socktype: 0), sock6.fd: 3 (socktype: SOCK_RAW), hints.ai_family: AF_INET6 ai->ai_family: AF_INET6, ai->ai_canonname: 'pkgs.netbird.io' PING pkgs.netbird.io (2a04:3542:1000:910:2465:1fff:fe8a:1d97) 56 data bytes 64 bytes from pkgs.netbird.io (2a04:3542:1000:910:2465:1fff:fe8a:1d97): icmp_seq=1 ident=57083 ttl=54 time=18.4 ms 64 bytes from pkgs.netbird.io (2a04:3542:1000:910:2465:1fff:fe8a:1d97): icmp_seq=2 ident=57083 ttl=54 time=13.1 ms 64 bytes from pkgs.netbird.io (2a04:3542:1000:910:2465:1fff:fe8a:1d97): icmp_seq=3 ident=57083 ttl=54 time=13.4 ms --- pkgs.netbird.io ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 13.061/14.948/18.368/2.422 ms ``` **To Reproduce** 1. Connect a Raspberry Pi 5 to BayernWLAN (public Wi-Fi hotspot). IPv6 is not available on this network. 2. Try accessing the package repo: - `curl -4 -v https://pkgs.netbird.io/` 3. Observe it hangs after: - `TLS handshake, Client hello` ``` * Trying 5.22.212.152:443... * Connected to pkgs.netbird.io (5.22.212.152) port 443 (#0) * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs ``` Additional tests show SNI-specific blocking: - With SNI (hangs): - `printf 'GET / HTTP/1.1\r\nHost: pkgs.netbird.io\r\nConnection: close\r\n\r\n' | openssl s_client -connect 5.22.212.152:443 -servername pkgs.netbird.io -quiet` - result: hangs - Without SNI (TLS works): - `printf 'GET / HTTP/1.1\r\nHost: pkgs.netbird.io\r\nConnection: close\r\n\r\n' | openssl s_client -connect 5.22.212.152:443 -noservername -quiet` - result: ``` depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R13 verify return:1 depth=0 CN = pkgs.netbird.io verify return:1 HTTP/1.1 200 OK Server: nginx Date: Fri, 13 Feb 2026 13:51:23 GMT Content-Type: application/octet-stream Content-Length: 2 Connection: close Content-Type: text/plain ``` - Connect by IP + set HTTP Host header (works): - `curl -4vk https://5.22.212.152/ -H 'Host: pkgs.netbird.io'` - Result: `HTTP/1.1 200 OK` Connectivity check: - `curl -I http://connectivitycheck.gstatic.com/generate_204` returns `HTTP/1.1 204 No Content` **Expected behavior** `https://pkgs.netbird.io` should be reachable from typical public Wi-Fi networks, or there should be an officially documented fallback installation/update path that does not depend on SNI to `pkgs.netbird.io` (e.g., a mirror hostname, or guidance to use an alternative distribution method). **Are you using NetBird Cloud?** yes **NetBird version** N/A – cannot install the client because the apt repo host `pkgs.netbird.io` is unreachable on this network. **Is any other VPN software installed?** Yes: Tailscale (only way atm accessing the Pi). **Debug output** Not available (NetBird client not installed yet). **Screenshots** N/A **Additional context** This looks like TLS SNI filtering on the hotspot: the connection only fails when the ClientHello contains SNI = `pkgs.netbird.io`. SNI is the TLS extension used to indicate the hostname during the handshake. - `cat /etc/os-release` ``` PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" ``` - `uname -a` ``` 6.6.78-v8-16k ``` - `curl --version` ``` curl 7.88.1 (aarch64-unknown-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.18 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13 Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u14 Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd ``` - `openssl version -a` ``` OpenSSL 3.0.18 30 Sep 2025 (Library: OpenSSL 3.0.18 30 Sep 2025) built on: Mon Feb 2 14:45:25 2026 UTC platform: debian-arm64 options: bn(64,64) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-hoDPI0/openssl-3.0.18=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/aarch64-linux-gnu/engines-3" MODULESDIR: "/usr/lib/aarch64-linux-gnu/ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_armcap=0xbd ``` - `tailscale version` ``` 1.94.1 tailscale commit: 62c6f1cd7560763edcc552251abadf7dd4659f82 long version: 1.94.1-t62c6f1cd7-g09fea6572 other commit: 09fea6572e9c7a839b4a8c209420141fdb33fbb4 go version: go1.25.5 ``` - ca-certificates are "up-to-date", latest in apt repo `apt list --installed | grep ca-cert` -> `ca-certificates/oldstable,oldstable,oldstable-updates,oldstable-updates,now 20230311+deb12u1 all [installed]` **Have you tried these troubleshooting steps?** - [x] Reviewed client troubleshooting (docs: `https://docs.netbird.io/how-to/troubleshooting-client`) - [x] Checked for newer NetBird versions - [x] Searched for similar issues on GitHub (including closed ones) - [x] Restarted the NetBird client - [ ] Disabled other VPN software - [x] Checked firewall settings
saavagebueno added the triage-needed label 2026-08-05 01:27:52 -04:00
Author
Owner

@a7md0 commented on GitHub (Jun 2, 2026):

I'm facing the same issue described here on different network. Unrelated to the machine trying the connection (Linux/Windows)

This can be either MTU issue from network/ISP OR there is deep packet inspection (DPI) blocking the specific domain

It would be great if Netbird can support Encrypted Client Hello (ECH) on their public repo pkgs.netbird.io

<!-- gh-comment-id:4607028892 --> @a7md0 commented on GitHub (Jun 2, 2026): I'm facing the same issue described here on different network. Unrelated to the machine trying the connection (Linux/Windows) This can be either MTU issue from network/ISP OR there is deep packet inspection (DPI) blocking the specific domain It would be great if Netbird can support Encrypted Client Hello (ECH) on their public repo `pkgs.netbird.io`
Author
Owner

@Socialpranker commented on GitHub (Jun 14, 2026):

Your own tests basically already answer this, fwiw — and it's not netbird's side.

The tell is that openssl s_client ... -servername pkgs.netbird.io hangs but -noservername returns a clean 200 OK from the same IP. If it were an MTU/fragmentation thing (the other theory in this thread), it'd hang regardless of what's in the ClientHello — MTU doesn't care about the SNI field. The fact that flipping only the SNI flips the outcome means something on-path is reading the hostname out of your ClientHello and dropping the flow. That's textbook SNI-based DPI filtering, and "BayernWLAN + Jugendschutzfilter" is exactly the kind of network that does it. The youth-filter probably has netbird (or the whole apt-repo pattern) on a list.

The IPv4 ping thing is a red herring — they're just dropping ICMP echo to that host, unrelated to the TLS hang.

So: their side would be ECH support (which @a7md0 already suggested and which would genuinely dodge this), but the block is the hotspot, not netbird. Quickest unblock on your end is a mirror/IP + Host: header, or DoH so the filter can't see the name.

Slightly self-promo but it's relevant: I got tired of eyeballing s_client output to make exactly this "my side / their side / the network in the middle" call, so I built a little local MCP server for it — netops-mcp. tls_inspect flags the SNI-conditional hang, and net_triangulate runs the same handshake from a bunch of other vantage points, so you get a flat "TLS to this host is fine from 8 other networks, only yours blocks it → it's the network" instead of arguing it out in a thread. Runs on your machine, read-only. Wouldn't have changed your diagnosis here since you nailed it, but it makes the next one a 10-second call.

<!-- gh-comment-id:4700750113 --> @Socialpranker commented on GitHub (Jun 14, 2026): Your own tests basically already answer this, fwiw — and it's not netbird's side. The tell is that `openssl s_client ... -servername pkgs.netbird.io` hangs but `-noservername` returns a clean `200 OK` from the same IP. If it were an MTU/fragmentation thing (the other theory in this thread), it'd hang regardless of what's in the ClientHello — MTU doesn't care about the SNI field. The fact that flipping *only* the SNI flips the outcome means something on-path is reading the hostname out of your ClientHello and dropping the flow. That's textbook SNI-based DPI filtering, and "BayernWLAN + Jugendschutzfilter" is exactly the kind of network that does it. The youth-filter probably has `netbird` (or the whole apt-repo pattern) on a list. The IPv4 ping thing is a red herring — they're just dropping ICMP echo to that host, unrelated to the TLS hang. So: their side would be ECH support (which @a7md0 already suggested and which would genuinely dodge this), but the *block* is the hotspot, not netbird. Quickest unblock on your end is a mirror/IP + `Host:` header, or DoH so the filter can't see the name. Slightly self-promo but it's relevant: I got tired of eyeballing `s_client` output to make exactly this "my side / their side / the network in the middle" call, so I built a little local MCP server for it — [netops-mcp](https://github.com/Socialpranker/netops-mcp). `tls_inspect` flags the SNI-conditional hang, and `net_triangulate` runs the same handshake from a bunch of other vantage points, so you get a flat "TLS to this host is fine from 8 other networks, only yours blocks it → it's the network" instead of arguing it out in a thread. Runs on your machine, read-only. Wouldn't have changed your diagnosis here since you nailed it, but it makes the next one a 10-second call.
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#10961