What's new

[RELEASE] TAILMON v1.0.10 -May 12, 2024- WireGuard-based Tailscale Installer, Configurator and Monitor (Now available in AMTM!)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Haha maybe you or @ColinTaylor can raise a ticket on Tailscales GitHub. Maybe other Arch Linux users (GLiNET, Openwrt) have a similar issue and it’ll gain traction (unless someone already complained..)
Meh. It's either probably "by design", or "for security reasons", or "due to limitations in the OS". ;)
 
No problem there with technical nous, was just seeing if you could, with ALL your current settings under userspace mode, make the change to kernel mode and see if it fails, thus confirming it is a mode change that makes it go TU. Thanks 🙏

I just switched to Kernel mode. The subnet routes to the RPis stopped working. I then switched back to Userspace mode and they immediately started working again.
 
I just switched to Kernel mode. The subnet routes to the RPis stopped working. I then switched back to Userspace mode and they immediately started working again.
Great, thanks for doing the trial, always great when it is repeatable :).

I can't help you fix it (not enough expertise) and I am not sure if ColinTaylor would ask you to turn off these and try again, to see if it is the combination with Kernel and either one or both of those, but you've certainly narrowed it down to the Kernel mode; either by itself or in combination with something else (e.g. QoS and AiProtection), whereas userspace doesn't get affected, either alone or by that combination. [you noted "I have QoS and AiProtection both enabled"].
 
Last edited:
I just switched to Kernel mode. The subnet routes to the RPis stopped working. I then switched back to Userspace mode and they immediately started working again.
I'm able to confirm the same behavior. When I switch to "standard" tailmon kernel mode, I can no longer access my router from remote. When I switch back to userspace mode, everything works perfectly. Not sure what it could be. But this is the same problem I've had from the start with kernel mode. Tested on both my GT-AX6000 and RT-AX88U.
 
Last edited:
Connecting to raspberrypi using local ip 192.168.*.* works normally In kernel mode.
If your trying to access using Tailnet ip which starts with 100.*.*.* requires the user to serve the services on Tailnet.

To access from the Internet remotely you need to use funnel.

Here are examples from Tailscale cli:

Code:
Serve content and local servers on your tailnet

USAGE
  tailscale serve <target>
  tailscale serve status [--json]
  tailscale serve reset

Tailscale Serve enables you to share a local server securely within your tailnet.

To share a local server on the internet, use `tailscale funnel`

<target> can be a file, directory, text, or most commonly the location to a service running on the
local machine. The location to the location service can be expressed as a port number (e.g., 3000),
a partial URL (e.g., localhost:3000), or a full URL including a path (e.g., http://localhost:3000/foo).

EXAMPLES
  - Expose an HTTP server running at 127.0.0.1:3000 in the foreground:
    $ tailscale serve 3000

  - Expose an HTTP server running at 127.0.0.1:3000 in the background:
    $ tailscale serve --bg 3000

  - Expose an HTTPS server with invalid or self-signed certificates at https://localhost:8443
    $ tailscale serve https+insecure://localhost:8443

For more examples and use cases visit our docs site https://tailscale.com/kb/1247/funnel-serve-use-cases

SUBCOMMANDS
  status  View current serve configuration
  reset   Reset current serve config

FLAGS
  --bg, --bg=false
        Run the command as a background process (default false)
  --http uint
        Expose an HTTP server at the specified port
  --https uint
        Expose an HTTPS server at the specified port (default mode)
  --set-path string
        Appends the specified path to the base URL for accessing the underlying service
  --tcp uint
        Expose a TCP forwarder to forward raw TCP packets at the specified port
  --tls-terminated-tcp uint
        Expose a TCP forwarder to forward TLS-terminated TCP packets at the specified port
  --yes, --yes=false
        Update without interactive prompts (default false)

Edit:
Would be helpful to debug the issue If people facing the issue with kernel mode to post how to replicate It.
 
Last edited:
Connecting to raspberrypi using local ip 192.168.*.* works normally In kernel mode.
If your trying to access using Tailnet ip which starts with 100.*.*.* requires the user to serve the services on Tailnet.

To access from the Internet remotely you need to use funnel.

Here are examples from Tailscale cli:

Code:
Serve content and local servers on your tailnet

USAGE
  tailscale serve <target>
  tailscale serve status [--json]
  tailscale serve reset

Tailscale Serve enables you to share a local server securely within your tailnet.

To share a local server on the internet, use `tailscale funnel`

<target> can be a file, directory, text, or most commonly the location to a service running on the
local machine. The location to the location service can be expressed as a port number (e.g., 3000),
a partial URL (e.g., localhost:3000), or a full URL including a path (e.g., http://localhost:3000/foo).

EXAMPLES
  - Expose an HTTP server running at 127.0.0.1:3000 in the foreground:
    $ tailscale serve 3000

  - Expose an HTTP server running at 127.0.0.1:3000 in the background:
    $ tailscale serve --bg 3000

  - Expose an HTTPS server with invalid or self-signed certificates at https://localhost:8443
    $ tailscale serve https+insecure://localhost:8443

For more examples and use cases visit our docs site https://tailscale.com/kb/1247/funnel-serve-use-cases

SUBCOMMANDS
  status  View current serve configuration
  reset   Reset current serve config

FLAGS
  --bg, --bg=false
        Run the command as a background process (default false)
  --http uint
        Expose an HTTP server at the specified port
  --https uint
        Expose an HTTPS server at the specified port (default mode)
  --set-path string
        Appends the specified path to the base URL for accessing the underlying service
  --tcp uint
        Expose a TCP forwarder to forward raw TCP packets at the specified port
  --tls-terminated-tcp uint
        Expose a TCP forwarder to forward TLS-terminated TCP packets at the specified port
  --yes, --yes=false
        Update without interactive prompts (default false)

Edit:
Would be helpful to debug the issue If people facing the issue with kernel mode to post how to replicate It.
Sure enough... that "tailscale serve" command did the trick... and I was able to get to my router web UI remotely in kernel mode! But what a PITA! You would have to run a separate command each time that would have it run in the background just for this to work... and may require one of the URL approvals each time. Actually, it looks like you can run the serve command without intervention the next time around. Still. UGH.

The fact that this just works out-of-the-box under userspace mode makes things so much easier. Think I'll just keep using that.

I appreciate your advice on this! :) @ColinTaylor... this might be a good addition for your Wiki?
 
Last edited:

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top