[Bug] autoApprove does not work for 0.0.0.0/0 and ::/0 #1010

Closed
opened 2025-12-29 02:27:25 +01:00 by adam · 6 comments
Owner

Originally created by @spymobilfon on GitHub (May 5, 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

Hello,
I hope you are doing well!

Sorry to bother but I think the fix #2550 did not help and broke workaround.

I was running Tailscale v1.82.5 on a Linux instance and Headscale v0.26.0-beta.1 as a controller on Linux as well.

The Tailscale client was started like this

tailscale up --login-server https://hsc.example.org --hostname='router-01' --advertise-exit-node=false --accept-routes=false --accept-dns=false --snat-subnet-routes=true --advertise-tags='tag:routers-vpn,tag:internet-routers' --advertise-routes='10.99.0.0/16,104.16.208.203/32,104.19.159.190/32,10.99.0.2/32'

Routers list looks like this

ID   | Hostname  | Approved | Available                                                        | Serving (Primary)
2414 | router-01 |          | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32 |

Then was started with empty advertise routes and again like this

tailscale up --login-server https://hsc.example.org --hostname='router-01' --advertise-exit-node=false --accept-routes=false --accept-dns=false --snat-subnet-routes=true --advertise-tags='tag:routers-vpn,tag:internet-routers' --advertise-routes='10.99.0.0/16,104.16.208.203/32,104.19.159.190/32,10.99.0.2/32'

Routers list looks like this

ID   | Hostname  | Approved                   | Available                                                        | Serving (Primary)
2414 | router-01 | 10.99.0.0/16, 10.99.0.2/32 | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32 | 10.99.0.0/16, 10.99.0.2/32

Routes to 104.16.208.203/32 and 104.19.159.190/32 was not approved.

autoApprove in ACL looks like this

...
"autoApprovers": {
    "routes": {
      "10.99.0.0/16": [
        "tag:routers-vpn"
      ],
      "0.0.0.0/0": [
        "tag:internet-routers"
      ],
      "::/0": [
        "tag:internet-routers"
      ]
    },
    "exitNode": [
      "tag:exit-nodes"
    ]
},
...

Expected Behavior

Have the routes auto-enabled from start

ID   | Hostname  | Approved                                                         | Available                                                        | Serving (Primary)
2414 | router-01 | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32 | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32 | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32

Steps To Reproduce

Config

---
server_url: https://hsc.example.org
listen_addr: 127.0.0.1:8080
metrics_listen_addr: 127.0.0.1:9090
grpc_listen_addr: 127.0.0.1:50443
grpc_allow_insecure: false

noise:
  private_key_path: /var/lib/headscale/noise_private.key

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48
  allocation: sequential

derp:
  server:
    enabled: false
    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/derp_server_private.key
    automatically_add_embedded_derp_region: true
    ipv4: 1.2.3.4
    ipv6: 2001:db8::1
  urls:
    - https://controlplane.tailscale.com/derpmap/default
  paths: []
  auto_update_enabled: true
  update_frequency: 24h

disable_check_updates: true
ephemeral_node_inactivity_timeout: 30m

database:
  type: postgres
  gorm:
    prepare_stmt: true
    parameterized_queries: true
    skip_err_record_not_found: true
    slow_threshold: 1000

  postgres:
    host: localhost
    port: 5432
    name: headscale
    user: headscale
    pass: xxxxxxxxxx
    max_open_conns: 10
    max_idle_conns: 10
    conn_max_idle_time_secs: 3600

acme_url: https://acme-v02.api.letsencrypt.org/directory
acme_email: admin@example.org

tls_letsencrypt_hostname: ""
tls_letsencrypt_cache_dir: /var/lib/headscale/cache
tls_letsencrypt_challenge_type: HTTP-01
tls_letsencrypt_listen: ":http"
tls_cert_path: ""
tls_key_path: ""

log:
  format: text
  level: debug

policy:
  mode: file
  path: /etc/headscale/acl.hujson

dns:
  magic_dns: false
  base_domain: vpn

  nameservers:
    global:
      - 1.1.1.1
    split:
      {}
  search_domains: []
  extra_records: []

unix_socket: /var/run/headscale/headscale.sock
unix_socket_permission: "0770"

oidc:
  only_start_if_oidc_is_available: true
  issuer: https://issuer.example.org
  client_id: headscale
  client_secret: xxxxxxxxxx
  expiry: 1d
  use_expiry_from_token: false
  scope: ["openid", "profile", "email"]
  allowed_domains:
    - example.org

logtail:
  enabled: false

randomize_client_port: false

Policy

{
  "groups": {
    "group:users": [
      "user1@example.org",
      "user2@example.org"
    ],
    "group:exit-nodes": [
      "exit-node@"
    ],
    "group:internet-routers": [
      "router-01@",
      "router-02@"
    ],
    "group:routers-vpn": [
      "router-01@",
      "router-02@"
    ]
  },
  "tagOwners": {
    "tag:routers-vpn": [
      "group:routers-vpn"
    ],
    "tag:internet-routers": [
      "group:internet-routers"
    ],
    "tag:exit-nodes": [
      "group:exit-nodes"
    ]
  },
  "autoApprovers": {
    "routes": {
      "10.99.0.0/16": [
        "tag:routers-vpn"
      ],
      "0.0.0.0/0": [
        "tag:internet-routers"
      ],
      "::/0": [
        "tag:internet-routers"
      ]
    },
    "exitNode": [
      "tag:exit-nodes"
    ]
  },
  "hosts": {
    "vpn-dns": "10.99.0.2/32",
    "vpn-network": "10.99.0.0/16"
  },
  "acls": [
    {
      "action": "accept",
      "src": [
        "*"
      ],
      "dst": [
        "vpn-dns:53",
        "0.0.0.0:53",
        "group:routers-vpn:0"
      ]
    },
    {
      "action": "accept",
      "src": [
        "group:users"
      ],
      "dst": [
        "group:exit-nodes:0",
        "autogroup:internet:*"
      ]
    },
    {
      "action": "accept",
      "src": [
        "group:users"
      ],
      "dst": [
        "group:routers-vpn:0",
        "vpn-network:*",
        "104.16.208.203:*",
        "104.19.159.190:*"
      ]
    }
  ]
}

Tailscale

tailscale up --login-server https://hsc.example.org --hostname='router-01' --advertise-exit-node=false --accept-routes=false --accept-dns=false --snat-subnet-routes=true --advertise-tags='tag:routers-vpn,tag:internet-routers' --advertise-routes='10.99.0.0/16,104.16.208.203/32,104.19.159.190/32,10.99.0.2/32'

Environment

- OS: Ubuntu 24.04
- Headscale version: v0.26.0-beta.1
- Tailscale version: v1.82.5

Runtime environment

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

Debug information

Route management is not logged.

Originally created by @spymobilfon on GitHub (May 5, 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 Hello, I hope you are doing well! Sorry to bother but I think the fix #2550 did not help and broke workaround. I was running Tailscale v1.82.5 on a Linux instance and Headscale v0.26.0-beta.1 as a controller on Linux as well. The Tailscale client was started like this ``` tailscale up --login-server https://hsc.example.org --hostname='router-01' --advertise-exit-node=false --accept-routes=false --accept-dns=false --snat-subnet-routes=true --advertise-tags='tag:routers-vpn,tag:internet-routers' --advertise-routes='10.99.0.0/16,104.16.208.203/32,104.19.159.190/32,10.99.0.2/32' ``` Routers list looks like this ``` ID | Hostname | Approved | Available | Serving (Primary) 2414 | router-01 | | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32 | ``` Then was started with empty advertise routes and again like this ``` tailscale up --login-server https://hsc.example.org --hostname='router-01' --advertise-exit-node=false --accept-routes=false --accept-dns=false --snat-subnet-routes=true --advertise-tags='tag:routers-vpn,tag:internet-routers' --advertise-routes='10.99.0.0/16,104.16.208.203/32,104.19.159.190/32,10.99.0.2/32' ``` Routers list looks like this ``` ID | Hostname | Approved | Available | Serving (Primary) 2414 | router-01 | 10.99.0.0/16, 10.99.0.2/32 | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32 | 10.99.0.0/16, 10.99.0.2/32 ``` Routes to 104.16.208.203/32 and 104.19.159.190/32 was not approved. autoApprove in ACL looks like this ``` ... "autoApprovers": { "routes": { "10.99.0.0/16": [ "tag:routers-vpn" ], "0.0.0.0/0": [ "tag:internet-routers" ], "::/0": [ "tag:internet-routers" ] }, "exitNode": [ "tag:exit-nodes" ] }, ... ``` ### Expected Behavior Have the routes auto-enabled from start ``` ID | Hostname | Approved | Available | Serving (Primary) 2414 | router-01 | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32 | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32 | 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32 ``` ### Steps To Reproduce Config ``` --- server_url: https://hsc.example.org listen_addr: 127.0.0.1:8080 metrics_listen_addr: 127.0.0.1:9090 grpc_listen_addr: 127.0.0.1:50443 grpc_allow_insecure: false noise: private_key_path: /var/lib/headscale/noise_private.key prefixes: v4: 100.64.0.0/10 v6: fd7a:115c:a1e0::/48 allocation: sequential derp: server: enabled: false 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/derp_server_private.key automatically_add_embedded_derp_region: true ipv4: 1.2.3.4 ipv6: 2001:db8::1 urls: - https://controlplane.tailscale.com/derpmap/default paths: [] auto_update_enabled: true update_frequency: 24h disable_check_updates: true ephemeral_node_inactivity_timeout: 30m database: type: postgres gorm: prepare_stmt: true parameterized_queries: true skip_err_record_not_found: true slow_threshold: 1000 postgres: host: localhost port: 5432 name: headscale user: headscale pass: xxxxxxxxxx max_open_conns: 10 max_idle_conns: 10 conn_max_idle_time_secs: 3600 acme_url: https://acme-v02.api.letsencrypt.org/directory acme_email: admin@example.org tls_letsencrypt_hostname: "" tls_letsencrypt_cache_dir: /var/lib/headscale/cache tls_letsencrypt_challenge_type: HTTP-01 tls_letsencrypt_listen: ":http" tls_cert_path: "" tls_key_path: "" log: format: text level: debug policy: mode: file path: /etc/headscale/acl.hujson dns: magic_dns: false base_domain: vpn nameservers: global: - 1.1.1.1 split: {} search_domains: [] extra_records: [] unix_socket: /var/run/headscale/headscale.sock unix_socket_permission: "0770" oidc: only_start_if_oidc_is_available: true issuer: https://issuer.example.org client_id: headscale client_secret: xxxxxxxxxx expiry: 1d use_expiry_from_token: false scope: ["openid", "profile", "email"] allowed_domains: - example.org logtail: enabled: false randomize_client_port: false ``` Policy ``` { "groups": { "group:users": [ "user1@example.org", "user2@example.org" ], "group:exit-nodes": [ "exit-node@" ], "group:internet-routers": [ "router-01@", "router-02@" ], "group:routers-vpn": [ "router-01@", "router-02@" ] }, "tagOwners": { "tag:routers-vpn": [ "group:routers-vpn" ], "tag:internet-routers": [ "group:internet-routers" ], "tag:exit-nodes": [ "group:exit-nodes" ] }, "autoApprovers": { "routes": { "10.99.0.0/16": [ "tag:routers-vpn" ], "0.0.0.0/0": [ "tag:internet-routers" ], "::/0": [ "tag:internet-routers" ] }, "exitNode": [ "tag:exit-nodes" ] }, "hosts": { "vpn-dns": "10.99.0.2/32", "vpn-network": "10.99.0.0/16" }, "acls": [ { "action": "accept", "src": [ "*" ], "dst": [ "vpn-dns:53", "0.0.0.0:53", "group:routers-vpn:0" ] }, { "action": "accept", "src": [ "group:users" ], "dst": [ "group:exit-nodes:0", "autogroup:internet:*" ] }, { "action": "accept", "src": [ "group:users" ], "dst": [ "group:routers-vpn:0", "vpn-network:*", "104.16.208.203:*", "104.19.159.190:*" ] } ] } ``` Tailscale ``` tailscale up --login-server https://hsc.example.org --hostname='router-01' --advertise-exit-node=false --accept-routes=false --accept-dns=false --snat-subnet-routes=true --advertise-tags='tag:routers-vpn,tag:internet-routers' --advertise-routes='10.99.0.0/16,104.16.208.203/32,104.19.159.190/32,10.99.0.2/32' ``` ### Environment ```markdown - OS: Ubuntu 24.04 - Headscale version: v0.26.0-beta.1 - Tailscale version: v1.82.5 ``` ### Runtime environment - [x] Headscale is behind a (reverse) proxy - [ ] Headscale runs in a container ### Debug information Route management is not logged.
adam added the bug label 2025-12-29 02:27:25 +01:00
adam closed this issue 2025-12-29 02:27:25 +01:00
Author
Owner

@nblock commented on GitHub (May 6, 2025):

Thanks for testing 0.26.0-beta.1! It seems that exit nodes and subnet routers are mixed up and that's causing issues
with your policy:

  • Your router does not announce itself as exit node: … --advertise-exit-node=false ….
  • The routes 0.0.0.0/0 and ::/0 can only be used to approve exit nodes. They cannot be used to approve arbitrary
    routes from a subnet router.
  • The routes 104.16.208.203/32 and 104.19.159.190/32 are not covered in the autoApprovers section of the policy
    and need to be approved manually.

Here is a similar (but simplified) policy where automatic approval during tailscale up works (0.26.0-beta.1).

{
  "groups": {
    "group:users": [
      "user1@",
    ],
    "group:routers": [
      "router@"
    ]
  },
  "tagOwners": {
    "tag:routers-vpn": [
      "group:routers"
    ],
    "tag:exit-nodes": [
      "group:routers"
    ]
  },
  "autoApprovers": {
    "routes": {
      "10.99.0.0/16": [
        "tag:routers-vpn"
      ]
    },
    "exitNode": [
      "tag:exit-nodes"
    ]
  },
  "hosts": {
    "vpn-dns": "10.99.0.2/32",
    "vpn-network": "10.99.0.0/16"
  },
  "acls": [
    {
      "action": "accept",
      "src": [
        "*"
      ],
      "dst": [
        "vpn-dns:53",
        "vpn-network:*",
        "autogroup:internet:*"
      ]
    }
  ]
}

Headscale:

$ headscale user list
ID | Name | Username | Email | Created
1  |      | user1    |       | 2025-05-06 11:00:39
2  |      | router   |       | 2025-05-06 11:00:42
$ headscale node list
ID | Hostname | Name     | MachineKey | NodeKey | User   | IP addresses                  | Ephemeral | Last seen | Expiration | Connected | Expired
1  | router01 | router01 | [A9J9T]    | [BlMzS] | router | 100.64.0.1, fd7a:115c:a1e0::1 | false     |           | N/A        | online    | no
2  | client   | client   | [teN34]    | [bEsIi] | user1  | 100.64.0.2, fd7a:115c:a1e0::2 | false     |           | N/A        | online    | no
$ headscale node list-routes
ID | Hostname | Approved                                    | Available                                                                         | Serving (Primary)
1  | router01 | 0.0.0.0/0, 10.99.0.0/16, 10.99.0.2/32, ::/0 | 0.0.0.0/0, 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32, ::/0 | 10.99.0.0/16, 10.99.0.2/32, 0.0.0.0/0, ::/0

Router:

$ sudo tailscale up \
    --login-server https://headscale.example.net \
    --hostname=router01 \
    --advertise-tags=tag:exit-nodes,tag:routers-vpn \
    --advertise-exit-node=true \
    --advertise-routes=10.99.0.0/16,104.16.208.203/32,104.19.159.190/32,10.99.0.2/32

Client:

$ sudo tailscale up \
    --login-server https://headscale.example.net \
    --hostname=client \
    --accept-routes=true

$ sudo tailscale exit-node list

 IP             HOSTNAME                    COUNTRY     CITY      STATUS
 100.64.0.1     router01.tn.example.com     -           -         -

Can you please update your policy based on the example above, especially the autoApprovers section? The docs for routes cover subnet routers and exit nodes with more explanation and examples: https://headscale.net/development/ref/routes/

@nblock commented on GitHub (May 6, 2025): Thanks for testing 0.26.0-beta.1! It seems that exit nodes and subnet routers are mixed up and that's causing issues with your policy: * Your router does not announce itself as exit node: `… --advertise-exit-node=false …`. * The routes `0.0.0.0/0` and `::/0` can only be used to approve exit nodes. They cannot be used to approve arbitrary routes from a subnet router. * The routes `104.16.208.203/32` and `104.19.159.190/32` are not covered in the `autoApprovers` section of the policy and need to be approved manually. Here is a similar (but simplified) policy where automatic approval during `tailscale up` works (0.26.0-beta.1). ```json { "groups": { "group:users": [ "user1@", ], "group:routers": [ "router@" ] }, "tagOwners": { "tag:routers-vpn": [ "group:routers" ], "tag:exit-nodes": [ "group:routers" ] }, "autoApprovers": { "routes": { "10.99.0.0/16": [ "tag:routers-vpn" ] }, "exitNode": [ "tag:exit-nodes" ] }, "hosts": { "vpn-dns": "10.99.0.2/32", "vpn-network": "10.99.0.0/16" }, "acls": [ { "action": "accept", "src": [ "*" ], "dst": [ "vpn-dns:53", "vpn-network:*", "autogroup:internet:*" ] } ] } ``` Headscale: ```console $ headscale user list ID | Name | Username | Email | Created 1 | | user1 | | 2025-05-06 11:00:39 2 | | router | | 2025-05-06 11:00:42 ``` ```console $ headscale node list ID | Hostname | Name | MachineKey | NodeKey | User | IP addresses | Ephemeral | Last seen | Expiration | Connected | Expired 1 | router01 | router01 | [A9J9T] | [BlMzS] | router | 100.64.0.1, fd7a:115c:a1e0::1 | false | | N/A | online | no 2 | client | client | [teN34] | [bEsIi] | user1 | 100.64.0.2, fd7a:115c:a1e0::2 | false | | N/A | online | no ``` ```console $ headscale node list-routes ID | Hostname | Approved | Available | Serving (Primary) 1 | router01 | 0.0.0.0/0, 10.99.0.0/16, 10.99.0.2/32, ::/0 | 0.0.0.0/0, 10.99.0.0/16, 10.99.0.2/32, 104.16.208.203/32, 104.19.159.190/32, ::/0 | 10.99.0.0/16, 10.99.0.2/32, 0.0.0.0/0, ::/0 ``` Router: ```console $ sudo tailscale up \ --login-server https://headscale.example.net \ --hostname=router01 \ --advertise-tags=tag:exit-nodes,tag:routers-vpn \ --advertise-exit-node=true \ --advertise-routes=10.99.0.0/16,104.16.208.203/32,104.19.159.190/32,10.99.0.2/32 ``` Client: ```console $ sudo tailscale up \ --login-server https://headscale.example.net \ --hostname=client \ --accept-routes=true $ sudo tailscale exit-node list IP HOSTNAME COUNTRY CITY STATUS 100.64.0.1 router01.tn.example.com - - - ``` Can you please update your policy based on the example above, especially the `autoApprovers` section? The docs for routes cover subnet routers and exit nodes with more explanation and examples: https://headscale.net/development/ref/routes/
Author
Owner

@spymobilfon commented on GitHub (May 6, 2025):

Thank you for your answer!
This news is upset me(
Our scheme has worked until v0.25.1, is broke only in 0.26.0-beta.1.
I showed only one simple example. We have many special routes to hosts in Internet (/32) and this IPs is changed often. Traffic is routed to this hosts via general routers, not via exit nodes. Manual approve many routes is so difficult and braeks scheme which we used in v0.23.0 and v0.22.3.
It looks like a breaking changes in 0.26.0-beta.1.
Will this behaviour to be in the next versions?

@spymobilfon commented on GitHub (May 6, 2025): Thank you for your answer! This news is upset me( Our scheme has worked until v0.25.1, is broke only in 0.26.0-beta.1. I showed only one simple example. We have many special routes to hosts in Internet (/32) and this IPs is changed often. Traffic is routed to this hosts via general routers, not via exit nodes. Manual approve many routes is so difficult and braeks scheme which we used in v0.23.0 and v0.22.3. It looks like a breaking changes in 0.26.0-beta.1. Will this behaviour to be in the next versions?
Author
Owner

@nblock commented on GitHub (May 6, 2025):

We have many special routes to hosts in Internet (/32) and this IPs is changed often. Traffic is routed to this hosts via general routers, not via exit nodes.

Can you elaborate a bit on your use-case? Do those /32 hosts share some prefix that could be auto approved at once?

@nblock commented on GitHub (May 6, 2025): > We have many special routes to hosts in Internet (/32) and this IPs is changed often. Traffic is routed to this hosts via general routers, not via exit nodes. Can you elaborate a bit on your use-case? Do those `/32` hosts share some prefix that could be auto approved at once?
Author
Owner

@spymobilfon commented on GitHub (May 6, 2025):

Of course.

Example we have a few Tailscale router nodes which responsible for access to special resources. It can be hosts (endpoints) our clients or our services or something else in Internet, it doesn't matter, example service desk portal or another portal or SSH service or RDP service. This endpoints can often change, dynamically add or remove. We restrict access to this routes via ACL.

We know how use DNS names with Tailscale instead of IPs. We don't know sometimes IPs which we should manually approve because IPs of DNS records can change. That's why advertise-routes can dynamically change.

This Tailscale routers have special tags like tag:internet-routers. We allow auto-approve anything routes (0.0.0.0/0) for this tags. We don't want approve each route to host (/32) because it's overhead. We don't want use exit-nodes for this purpose because we don't want to route all traffic via exit-nodes, only for special routes.

I hope that I describe my scheme understandable.

@spymobilfon commented on GitHub (May 6, 2025): Of course. Example we have a few Tailscale router nodes which responsible for access to special resources. It can be hosts (endpoints) our clients or our services or something else in Internet, it doesn't matter, example service desk portal or another portal or SSH service or RDP service. This endpoints can often change, dynamically add or remove. We restrict access to this routes via ACL. We know how use DNS names with Tailscale instead of IPs. We don't know sometimes IPs which we should manually approve because IPs of DNS records can change. That's why advertise-routes can dynamically change. This Tailscale routers have special tags like tag:internet-routers. We allow auto-approve anything routes (0.0.0.0/0) for this tags. We don't want approve each route to host (/32) because it's overhead. We don't want use exit-nodes for this purpose because we don't want to route all traffic via exit-nodes, only for special routes. I hope that I describe my scheme understandable.
Author
Owner

@nblock commented on GitHub (May 10, 2025):

I hope that I describe my scheme understandable.

Thanks for describing your use case. Headscale 0.26.0-beta.2 is now available and should support your use case. You may want to check if everything works as expected.

@nblock commented on GitHub (May 10, 2025): > I hope that I describe my scheme understandable. Thanks for describing your use case. [Headscale 0.26.0-beta.2](https://github.com/juanfont/headscale/releases/tag/v0.26.0-beta.2) is now available and should support your use case. You may want to check if everything works as expected.
Author
Owner

@spymobilfon commented on GitHub (May 13, 2025):

Yes, it works. Thank you.

@spymobilfon commented on GitHub (May 13, 2025): Yes, it works. Thank you.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1010