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] tailscale accept a local subnet #1148

New Issue
Closed
opened 2025-12-29 02:28:34 +01:00 by adam · 3 comments
adam commented 2025-12-29 02:28:34 +01:00
Owner
Copy Link

Originally created by @IamTaoChen on GitHub (Nov 15, 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

My network(192.168.1.0/24) contains 2 tailscale clilents, A(192.168.1.10) and B(192.168.1.20).

  1. A run with --advertise-routes=192.168.1.0/24
  2. if B set --accept-routes, then the B will be lost

I'm not sure if this is caused by tailscale or headacale

Expected Behavior

B should ignore local network?

Steps To Reproduce

see above

Environment

- OS: docker
- Headscale version: 0.27.1
- Tailscale version: 1.90.6

Runtime environment

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

Debug information

none

Originally created by @IamTaoChen on GitHub (Nov 15, 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 My network(`192.168.1.0/24`) contains 2 tailscale clilents, A(`192.168.1.10`) and B(`192.168.1.20`). 1. A run with `--advertise-routes=192.168.1.0/24` 2. if B `set --accept-routes`, then the B will be lost I'm not sure if this is caused by tailscale or headacale ### Expected Behavior B should ignore local network? ### Steps To Reproduce see above ### Environment ```markdown - OS: docker - Headscale version: 0.27.1 - Tailscale version: 1.90.6 ``` ### Runtime environment - [x] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container ### Debug information none
adam added the bug label 2025-12-29 02:28:34 +01:00
adam closed this issue 2025-12-29 02:28:34 +01:00
adam commented 2025-12-29 02:28:34 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (Nov 15, 2025):

I'm not sure if this is caused by tailscale or headacale

Haven't looked at it yet, but could this be:

@nblock commented on GitHub (Nov 15, 2025): > I'm not sure if this is caused by tailscale or headacale Haven't looked at it yet, but could this be: - https://github.com/tailscale/tailscale/issues/6231 - https://github.com/tailscale/tailscale/issues/1227
adam commented 2025-12-29 02:28:34 +01:00
Author
Owner
Copy Link

@YouSysAdmin commented on GitHub (Nov 15, 2025):

Hi.
This isn't a Headscale bug, and it's not really a bug at all, but a classic cross-network routing issue. :)

Root:
Tailscale add different route table (52)

router:~$ ip rule show
0:      from all lookup local
5210:   from all fwmark 0x80000/0xff0000 lookup main
5230:   from all fwmark 0x80000/0xff0000 lookup default
5250:   from all fwmark 0x80000/0xff0000 unreachable
5270:   from all lookup 52 <--- tailscale
32766:  from all lookup main
32767:  from all lookup default

This table have priority index 5270 but your main table have priority 32766 - any tailscale routes prioritize on main table.

Is it possible to change the priority? Yes, it is possible, but you will immediately encounter the exact opposite problem: you won't be able to access remote network resources.

Solution:

  1. Use different networks on the client side. You have 10.0.0.0/8 for this purpose, which is enough for everyone.
    For example: if you have two offices, the first office uses 10.1.0.0/24, the second 10.2.0.0/24, and so on (or for your situation 192.168.1.0/24 + 192.168.2.0/24).
  2. Declare only the necessary hosts via the /32 mask, for example, 192.168.0.5/32 - this will not solve the conflict problem, but it will not completely destroy the network, but the local 192.168.0.5 will not be accessible to the user.
  3. Don't announce routes, use tailscale serve for share access to a services.

Solution 1 - as rule for any cross-network connections.
You can resist this as much as you want, but all routing has been built on this since time immemorial. There are ways to get around this, but neither you nor your users will like it :)

P.S. It is no coincidence that Tailscale chose the 100.64.0.0/10 network for cross-client connections - this is a little-known range, and its use minimizes the risk of conflicts in clients' local networks.
But all other conflicts is this is the users area of ​​responsibility.

I wouldn't expect Tailscale to solve this problem on its side, there are solutions, but they are unstable in their behavior.

@YouSysAdmin commented on GitHub (Nov 15, 2025): Hi. This isn't a Headscale bug, and it's not really a bug at all, but a classic cross-network routing issue. :) **Root:** Tailscale add different route table (52) ``` router:~$ ip rule show 0: from all lookup local 5210: from all fwmark 0x80000/0xff0000 lookup main 5230: from all fwmark 0x80000/0xff0000 lookup default 5250: from all fwmark 0x80000/0xff0000 unreachable 5270: from all lookup 52 <--- tailscale 32766: from all lookup main 32767: from all lookup default ``` This table have priority index `5270` but your `main` table have priority `32766` - any tailscale routes prioritize on `main` table. Is it possible to change the priority? Yes, it is possible, but you will immediately encounter the exact opposite problem: you won't be able to access remote network resources. **Solution:** 1. Use different networks on the client side. You have 10.0.0.0/8 for this purpose, which is enough for everyone. For example: if you have two offices, the first office uses 10.1.0.0/24, the second 10.2.0.0/24, and so on (or for your situation 192.168.1.0/24 + 192.168.2.0/24). 2. Declare only the necessary hosts via the /32 mask, for example, 192.168.0.5/32 - this will not solve the conflict problem, but it will not completely destroy the network, but the local 192.168.0.5 will not be accessible to the user. 3. Don't announce routes, use `tailscale serve` for share access to a services. **Solution 1** - as rule for any cross-network connections. You can resist this as much as you want, but all routing has been built on this since time immemorial. There are ways to get around this, but neither you nor your users will like it :) P.S. It is no coincidence that Tailscale chose the `100.64.0.0/10` network for cross-client connections - this is a little-known range, and its use minimizes the risk of conflicts in clients' local networks. But all other conflicts is this is the users area of ​​responsibility. I wouldn't expect Tailscale to solve this problem on its side, there are solutions, but they are unstable in their behavior.
adam commented 2025-12-29 02:28:34 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (Nov 15, 2025):

Thx for looking into it and providing a detailed explanation.

@nblock commented on GitHub (Nov 15, 2025): Thx for looking into it and providing a detailed explanation.
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#1148
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?