mirror of
https://github.com/juanfont/headscale.git
synced 2026-01-11 20:00:28 +01:00
node in exit-node mode not forwarding traffic to same network which belongs external interface #589
Reference in New Issue
Block a user
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?
Originally created by @winterheart on GitHub (Dec 8, 2023).
Bug description
I have two nodes in headscale/tailscale network, one of them is exit-node with external IP:
node1 (exit-node):
node2 (client)
When I try use node1 as exit-node, it works as expected except that fact I cannot access to any IP address of external subnet 88.88.88.0/24 (same network for node1):
After switch to exit-node there no any traffic on
tailscale0interface on node1 related to 88.88.88.3, but any other external traffic from node2 to the Internet goes without any problems.Environment
Exit node has
-A POSTROUTING -o tailscale0 -j MASQUERADEiptables rule in nat table.ACL related to exit-nodes (user in
adminsandexitpointsgroups, node1 hasexitpointstag):To Reproduce
Run two clients, one as exit-node with external interface. Add relevant ACL to allow using exit-node. Enable exit-node on second client and try to access to any IP from exit-node external subnet.
@kradalby commented on GitHub (Dec 10, 2023):
0.23.0-alpha2 addresses a series of issues with node synchronisation, online status and subnet routers, please test this release and report back if the issue still persist.
@winterheart commented on GitHub (Dec 13, 2023):
Hello. Cannot verify 0.23.0-alpha2 due #1604 issue. Seems subnet router feature broken on old configuration and new version.
@r1s1us commented on GitHub (Dec 25, 2023):
Hello, I have the same problem, because of which I can't use the application in the enterprise(can't get acl and exit-node to work) how to fix this problem? On 0.23.0-alpha2 the problem remains(
@kradalby commented on GitHub (Jan 3, 2024):
@winterheart am I correct to understand that this is a problem in versions prior to the new 0.23.0 alpha releases?
@winterheart commented on GitHub (Jan 3, 2024):
Yes, problem occurs in current stable 0.22.3.
@kradalby commented on GitHub (Jan 3, 2024):
@winterheart could you attempt to run this again with https://github.com/juanfont/headscale/pull/1673? It fixes the subnet router for 0.23.0.
If that does not fix it, we will move on with 0.23.0 first, as this is not a new bug (present in 0.22.3) and then fix it in future versions, not holding up 0.23.0 any longer.
@ChibangLW commented on GitHub (Feb 20, 2024):
@winterheart tailscale has the flag
--exit-node-allow-lan-accesswhich is disabled by default. Did you used that flag?Given that 10.1.0.2/24 is not in your ACL it should not be accessible to node1 via headscale. Doesn't really matter in this case as it is directly connected anyway.
@winterheart commented on GitHub (Mar 25, 2024):
I've retested with 0.23.0-alpha5 and
--exit-node-allow-lan-accesson node2 and still same problem, no access to external IP of node1.@ChibangLW commented on GitHub (Mar 25, 2024):
From my understanding to option should be used on node1, because you try to connect to the directly connected network on node1 from node2. It's an option for the exit-node.
@winterheart commented on GitHub (Mar 25, 2024):
--exit-node-allow-lan-accesscan be used only with--exit-node=<node>so I really no idea how use it on exit node but not in node that tries connect to.@ChibangLW commented on GitHub (Mar 25, 2024):
Okay never mind, I misunderstood the option.
EDIT: for clarification from the source code:
@ElyasAsmad commented on GitHub (Mar 30, 2024):
Any update on this matter? I have been tinkering around with WireGuard & OpenVPN because of this issue and by far only headscale meets my requirement
@winterheart commented on GitHub (May 14, 2024):
Retested on 0.23.0-alpha11, problem still occurs.
@github-actions[bot] commented on GitHub (Aug 13, 2024):
This issue is stale because it has been open for 90 days with no activity.
@github-actions[bot] commented on GitHub (Aug 21, 2024):
This issue was closed because it has been inactive for 14 days since being marked as stale.
@arthur-lbchn commented on GitHub (Jul 14, 2025):
Hi, I'm facing exactly the same issue as the original reporter. While connected to the exit node with a public IP address from a /27 network, I cannot reach any other hosts in this /27 network. I don't have any ACLs configured. The hosts are reachable when not connected to the exit node and are also reachable from the exit node itself.