starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Bug] Failed to read headscale configuration error="server_url cannot contain the base_domain, this will cause the headscale server and embedded DERP to become unreachable from the Tailscale node." #771

New Issue
Closed
opened 2025-12-29 02:23:48 +01:00 by adam · 4 comments
adam commented 2025-12-29 02:23:48 +01:00
Owner
Copy Link

Originally created by @super-ben on GitHub (Aug 21, 2024).

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

Since upgrading to v0.23.0-beta2, if I have, say headscale.mydomain.com in both server_url and base_domain, I get the error 'Failed to read headscale configuration error="server_url cannot contain the base_domain, this will cause the headscale server and embedded DERP to become unreachable from the Tailscale node."', and the headscale server cannot even start.

While on some level I can understand the issue, on beta1 and earlier versions I had both set up with the same domain and worked like a charm. I'm also not against changing it, for testing purposes I've changed the base_domain back to example.com, because it failed to work even with mydomain.com, so it works now but at this point I'm unsure how to set these to values if I only have headscale.mydomain.com (as a sub-domain) and mydomain.com.

Expected Behavior

I would be happy if it either worked like before or accepted my domain (mydomain.com), as I don't really have anything in between and wouldn't want to use some bogus domain (like example.com, while doesn't cause an operational issue, I don't like it's optics).

Steps To Reproduce

  1. On Ubuntu 22.04
  2. Using Docker and Docker Compose
  3. I've upgraded to 0.23-beta2 from 0.23-beta1
  4. Also downloaded the latest config.yaml, changing only my relevant strings (server_url, base_domain, listening_port)

Environment

- OS: Ubuntu 22.04.1
- Headscale version: v0.23-beta2
- Tailscale version:1.72.0

Runtime environment

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

Anything else?

2024-08-21T08:29:02Z FTL Failed to read headscale configuration error="server_url cannot contain the base_domain, this will cause the headscale server and embedded DERP to become unreachable from the Tailscale node."

Originally created by @super-ben on GitHub (Aug 21, 2024). ### 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 Since upgrading to v0.23.0-beta2, if I have, say headscale.mydomain.com in both server_url and base_domain, I get the error 'Failed to read headscale configuration error="server_url cannot contain the base_domain, this will cause the headscale server and embedded DERP to become unreachable from the Tailscale node."', and the headscale server cannot even start. While on some level I can understand the issue, on beta1 and earlier versions I had both set up with the same domain and worked like a charm. I'm also not against changing it, for testing purposes I've changed the base_domain back to example.com, because it failed to work even with mydomain.com, so it works now but at this point I'm unsure how to set these to values if I only have headscale.mydomain.com (as a sub-domain) and mydomain.com. ### Expected Behavior I would be happy if it either worked like before or accepted my domain (mydomain.com), as I don't really have anything in between and wouldn't want to use some bogus domain (like example.com, while doesn't cause an operational issue, I don't like it's optics). ### Steps To Reproduce 1. On Ubuntu 22.04 2. Using Docker and Docker Compose 3. I've upgraded to 0.23-beta2 from 0.23-beta1 4. Also downloaded the latest config.yaml, changing only my relevant strings (server_url, base_domain, listening_port) ### Environment ```markdown - OS: Ubuntu 22.04.1 - Headscale version: v0.23-beta2 - Tailscale version:1.72.0 ``` ### Runtime environment - [X] Headscale is behind a (reverse) proxy - [X] Headscale runs in a container ### Anything else? 2024-08-21T08:29:02Z FTL Failed to read headscale configuration error="server_url cannot contain the base_domain, this will cause the headscale server and embedded DERP to become unreachable from the Tailscale node."
adam added the bug label 2025-12-29 02:23:48 +01:00
adam closed this issue 2025-12-29 02:23:48 +01:00
adam commented 2025-12-29 02:23:48 +01:00
Author
Owner
Copy Link

@mitchellkellett commented on GitHub (Aug 21, 2024):

This isn't a bug; this was a deliberate change. The below pull in the change log is the cause.

ac8491efec Redo DNS configuration (https://github.com/juanfont/headscale/pull/2034)

TLDR; you need to have your tailnet different to the URL for headscale.

eg.
server_url = example.com
base_domain = clients.example.com

@mitchellkellett commented on GitHub (Aug 21, 2024): This isn't a bug; this was a deliberate change. The below pull in the change log is the cause. https://github.com/juanfont/headscale/commit/ac8491efec4b5ed088ce90e48d14136a1fe228da Redo DNS configuration (https://github.com/juanfont/headscale/pull/2034) TLDR; you need to have your tailnet different to the URL for headscale. eg. server_url = example.com base_domain = clients.example.com
adam commented 2025-12-29 02:23:49 +01:00
Author
Owner
Copy Link

@super-ben commented on GitHub (Aug 21, 2024):

Alright, thanks, will do this, then. I wasn't aware of the mentioned PR.

@super-ben commented on GitHub (Aug 21, 2024): Alright, thanks, will do this, then. I wasn't aware of the mentioned PR.
adam commented 2025-12-29 02:23:49 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Aug 21, 2024):

Thanks @mitchellkellett, this is intentional and there is longer explanations in the comment of the code and that pr.

@kradalby commented on GitHub (Aug 21, 2024): Thanks @mitchellkellett, this is intentional and there is longer explanations in the comment of the code and that pr.
adam commented 2025-12-29 02:23:49 +01:00
Author
Owner
Copy Link

@renne commented on GitHub (Jan 10, 2025):

Is the possible name conflict between Headscale server and a Tailscale node the only reason for not allowing
Headscale server: server.example.com
Base domain: example.com
or are there other reasons for this decision?

It's quite annoying to have to use another 2nd-level domain for the Headscale server or an additional subdomain for the Tailscale nodes.

If it is just the possible name collision, reserving the hostname of the Headscale server would do the trick.

In my case it is a more complex Split-DNS setup for a DNS query to make TLS certificates usable in the LAN:

1. Return static A/AAAA/HTTPS records for some hosts

2a. if subnet is 10.0.0.0/24, 192.168.178.0/24, aaaa:bbbb:cccc:dddd::/64 or aaaa:bbbb:eeee:ffff::/64 rewrite suffix example.com to fritz.box and forward fritz.box to 10.0.0.1 on NXDOMAIN forward example.com to 100.100.100.100

2b. if subnet is 100.64.0.0/10 or fd7a:115c:a1e0::/48 forward example.com to 100.100.100.100 on NXDOMAIN rewrite suffix example.com to fritz.box and forward fritz.box to 10.0.0.1

3. on NXDOMAIN forward example.com to authoritative nameservers of example.com

Using an additional sub-domain means additional rewrites and queries.

@renne commented on GitHub (Jan 10, 2025): Is the possible name conflict between Headscale server and a Tailscale node the only reason for not allowing Headscale server: `server.example.com` Base domain: `example.com` or are there other reasons for this decision? It's quite annoying to have to use another 2nd-level domain for the Headscale server or an additional subdomain for the Tailscale nodes. If it is just the possible name collision, reserving the hostname of the Headscale server would do the trick. In my case it is a more complex Split-DNS setup for a DNS query to make TLS certificates usable in the LAN: ``` 1. Return static A/AAAA/HTTPS records for some hosts 2a. if subnet is 10.0.0.0/24, 192.168.178.0/24, aaaa:bbbb:cccc:dddd::/64 or aaaa:bbbb:eeee:ffff::/64 rewrite suffix example.com to fritz.box and forward fritz.box to 10.0.0.1 on NXDOMAIN forward example.com to 100.100.100.100 2b. if subnet is 100.64.0.0/10 or fd7a:115c:a1e0::/48 forward example.com to 100.100.100.100 on NXDOMAIN rewrite suffix example.com to fritz.box and forward fritz.box to 10.0.0.1 3. on NXDOMAIN forward example.com to authoritative nameservers of example.com ``` Using an additional sub-domain means additional rewrites and queries.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#771
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?