[Bug] cant connect over ipv6 only connection #1096

Closed
opened 2025-12-29 02:28:15 +01:00 by adam · 4 comments
Owner

Originally created by @bigpod98 on GitHub (Sep 11, 2025).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

i have a device that only has public ipv6 assigned when i try to connect to headscale server all i get on headscale side is ERR user msg: node not found code=404 to me this looks like a bug as same device can connect to tailscale proper and can access the server if i hit from that device to nginx running on headscale server(did this for debug purposes using curl)

Expected Behavior

for headscale to add the node to tailnet

Steps To Reproduce

config:

---
server_url: [redacted for security]
listen_addr: 0.0.0.0:443
metrics_listen_addr: 127.0.0.1:9090

grpc_listen_addr: 127.0.0.1:50443
grpc_allow_insecure: true
noise:
  private_key_path: /var/lib/headscale/noise1_private.key
prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48
  allocation: sequential
derp:
  server:
    enabled: true
    region_id: 999
    region_code: "headscale"
    region_name: "Headscale Embedded DERP"
    stun_listen_addr: "0.0.0.0:3478"
    private_key_path: /var/lib/headscale/derp1_server_private.key
    automatically_add_embedded_derp_region: true
  urls:
    - https://controlplane.tailscale.com/derpmap/default
  paths: []
  auto_update_enabled: true

  update_frequency: 24h
disable_check_updates: false

ephemeral_node_inactivity_timeout: 30m

database:
  type: sqlite
  debug: false
  gorm:
    prepare_stmt: true
    parameterized_queries: true
    skip_err_record_not_found: true

    slow_threshold: 1000
  sqlite:
    path: /var/lib/headscale/db1.sqlite
    write_ahead_log: true
    wal_autocheckpoint: 1000
acme_url: https://acme-v02.api.letsencrypt.org/directory
acme_email: "[redacted for security]"

# Domain name to request a TLS certificate for:
tls_letsencrypt_hostname: "[redacted for security]"
tls_letsencrypt_cache_dir: /var/lib/headscale/cache1
tls_letsencrypt_challenge_type: HTTP-01
# :http = port 80
tls_letsencrypt_listen: ":http"

tls_cert_path: ""
tls_key_path: ""

log:
  format: text
  level: debug
policy:
  mode: database
  path: ""
dns:
  magic_dns: true

  base_domain: example.com

  override_local_dns: false

  nameservers:
    global:
      - 1.1.1.1
  extra_records: []
unix_socket: /var/run/headscale/headscale.sock
unix_socket_permission: "0770"
logtail:
  enabled: false
randomize_client_port: false

Environment

- OS: almalinux 9.6
- Headscale version: 0.26.1
- Tailscale version: 1.86.2

Runtime environment

  • Headscale runs in a container
  • Headscale is behind a (reverse) proxy

Debug information

this is error while tailscale client is trying to connect
ERR user msg: node not found code=404

Originally created by @bigpod98 on GitHub (Sep 11, 2025). ### Is this a support request? - [x] This is not a support request ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior i have a device that only has public ipv6 assigned when i try to connect to headscale server all i get on headscale side is ERR user msg: node not found code=404 to me this looks like a bug as same device can connect to tailscale proper and can access the server if i hit from that device to nginx running on headscale server(did this for debug purposes using curl) ### Expected Behavior for headscale to add the node to tailnet ### Steps To Reproduce config: ``` --- server_url: [redacted for security] listen_addr: 0.0.0.0:443 metrics_listen_addr: 127.0.0.1:9090 grpc_listen_addr: 127.0.0.1:50443 grpc_allow_insecure: true noise: private_key_path: /var/lib/headscale/noise1_private.key prefixes: v4: 100.64.0.0/10 v6: fd7a:115c:a1e0::/48 allocation: sequential derp: server: enabled: true region_id: 999 region_code: "headscale" region_name: "Headscale Embedded DERP" stun_listen_addr: "0.0.0.0:3478" private_key_path: /var/lib/headscale/derp1_server_private.key automatically_add_embedded_derp_region: true urls: - https://controlplane.tailscale.com/derpmap/default paths: [] auto_update_enabled: true update_frequency: 24h disable_check_updates: false ephemeral_node_inactivity_timeout: 30m database: type: sqlite debug: false gorm: prepare_stmt: true parameterized_queries: true skip_err_record_not_found: true slow_threshold: 1000 sqlite: path: /var/lib/headscale/db1.sqlite write_ahead_log: true wal_autocheckpoint: 1000 acme_url: https://acme-v02.api.letsencrypt.org/directory acme_email: "[redacted for security]" # Domain name to request a TLS certificate for: tls_letsencrypt_hostname: "[redacted for security]" tls_letsencrypt_cache_dir: /var/lib/headscale/cache1 tls_letsencrypt_challenge_type: HTTP-01 # :http = port 80 tls_letsencrypt_listen: ":http" tls_cert_path: "" tls_key_path: "" log: format: text level: debug policy: mode: database path: "" dns: magic_dns: true base_domain: example.com override_local_dns: false nameservers: global: - 1.1.1.1 extra_records: [] unix_socket: /var/run/headscale/headscale.sock unix_socket_permission: "0770" logtail: enabled: false randomize_client_port: false ``` ### Environment ```markdown - OS: almalinux 9.6 - Headscale version: 0.26.1 - Tailscale version: 1.86.2 ``` ### Runtime environment - [ ] Headscale runs in a container - [ ] Headscale is behind a (reverse) proxy ### Debug information this is error while tailscale client is trying to connect ERR user msg: node not found code=404
adam added the bug label 2025-12-29 02:28:15 +01:00
adam closed this issue 2025-12-29 02:28:15 +01:00
Author
Owner

@ldesgoui commented on GitHub (Sep 15, 2025):

Try replacing listen_addr: 0.0.0.0:443 with listen_addr: [::]:443

@ldesgoui commented on GitHub (Sep 15, 2025): Try replacing `listen_addr: 0.0.0.0:443` with `listen_addr: [::]:443`
Author
Owner

@bigpod98 commented on GitHub (Sep 25, 2025):

i tried if i remember correctly but it dint work in some way specifically just checked Error is FTL ../../../home/runner/work/headscale/headscale/cmd/headscale/cli/root.go:55 > Error loading config error="fatal error reading config file: While parsing config: yaml: line 17: did not find expected node content"

@bigpod98 commented on GitHub (Sep 25, 2025): i tried if i remember correctly but it dint work in some way specifically just checked Error is FTL ../../../home/runner/work/headscale/headscale/cmd/headscale/cli/root.go:55 > Error loading config error="fatal error reading config file: While parsing config: yaml: line 17: did not find expected node content"
Author
Owner

@nblock commented on GitHub (Oct 11, 2025):

Error loading config error="fatal error reading config file: While parsing config: yaml: line 17: did not find expected node content"

You need to quote the value: listen_addr: "[::]:443"


Did some quick tests with listen_addr: 0.0.0.0:8443 and listen_addr: "[::]:8443" and I could always connect via IPv4 and IPv6. The socket looks identical in both cases:

Headscale log: INF listening and serving HTTP on: 0.0.0.0:8443:

# ss -tulpn | grep 8443
tcp   LISTEN 0      1024                                          *:8443             *:*    users:(("headscale",pid=15200,fd=13))

Headscale log: INF listening and serving HTTP on: [::]:8443:

# ss -tulpn | grep 8443
tcp   LISTEN 0      1024                                          *:8443             *:*    users:(("headscale",pid=15264,fd=13)) 
@nblock commented on GitHub (Oct 11, 2025): > Error loading config error="fatal error reading config file: While parsing config: yaml: line 17: did not find expected node content" You need to quote the value: `listen_addr: "[::]:443"` --- Did some quick tests with `listen_addr: 0.0.0.0:8443` and `listen_addr: "[::]:8443"` and I could always connect via IPv4 and IPv6. The socket looks identical in both cases: Headscale log: `INF listening and serving HTTP on: 0.0.0.0:8443`: ```console # ss -tulpn | grep 8443 tcp LISTEN 0 1024 *:8443 *:* users:(("headscale",pid=15200,fd=13)) ``` Headscale log: `INF listening and serving HTTP on: [::]:8443`: ```console # ss -tulpn | grep 8443 tcp LISTEN 0 1024 *:8443 *:* users:(("headscale",pid=15264,fd=13)) ```
Author
Owner

@nblock commented on GitHub (Oct 22, 2025):

Tested listen_addr: 0.0.0.0:8443 on Alma Linux 9 and it also binds on both IPv4 and IPv6. A client can connect fine when forced on either IP stack (using /etc/hosts IPv4 / IPv6 override).

@nblock commented on GitHub (Oct 22, 2025): Tested `listen_addr: 0.0.0.0:8443` on Alma Linux 9 and it also binds on both IPv4 and IPv6. A client can connect fine when forced on either IP stack (using `/etc/hosts` IPv4 / IPv6 override).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1096