Tailscale on a Jailbroken Kindle: SSH, Proxy Mode, and TUN

If you’ve ever tried to use a jailbroken e-ink reader as a tiny “always-on dashboard,” you probably hit the same weird wall: the device shows up on your private network, but apps still can’t reach other machines on that network.

That’s exactly where the newer Tailscale community work helps. It turns a jailbroken Kindle from “reachable over Tailscale” into something closer to “useable as a client for other tailnet services,” with three main upgrades: Tailscale SSH enabled by default, a proxy mode that lets apps like KOReader reach your other Tailscale nodes, and (on some devices) a full kernel TUN mode that can make the networking behave much more like a normal Linux machine. (tailscale.com)

This post walks through the ideas in plain language, then shows how the proxy and TUN modes fit together.

The baseline problem: “reachable” isn’t the same as “routable”

A tailnet is Tailscale’s term for your private mesh network—every device on the tailnet gets encrypted connectivity without you manually setting up VPN tunnels.

When you install Tailscale on a jailbroken Kindle, you can often get the Kindle to show up on your tailnet and even accept inbound connections. But that doesn’t automatically mean the Kindle’s operating system can route outbound traffic through Tailscale for arbitrary destinations.

Why do apps fail to reach other tailnet devices when Tailscale is running in userspace mode?

Because userspace networking means the networking behavior isn’t happening through the device’s normal packet-routing layer. Instead, Tailscale runs in a way where other programs may have to “go through” a proxy interface rather than relying on transparent routing. In the blog post’s example flow, KOReader tries to reach a Tailscale IP like 100.x.y.z, the Kindle OS can’t reach that IP directly, and KOReader drops the connection. ()

That’s the gap the proxy mode closes.

First upgrade: Tailscale SSH enabled by default

Before dealing with proxies, it helps to have a reliable way to log into the Kindle for debugging.

Tailscale SSH is a Tailscale feature that routes SSH traffic (the kind of terminal access used for Linux maintenance) over your tailnet while keeping it restricted to tailnet sources. When enabled, Tailscale claims port 22 on the device’s Tailscale IP—so traffic coming from your tailnet gets forwarded to an SSH server managed by Tailscale. (tailscale.com)

On the jailbroken Kindle side, the community update enables this behavior by default, avoiding the hassle of enabling SSH through more manual Kindle-specific methods (like default credentials that are… not great). ()

Two practical implications matter for security and sanity:

• Access controls still apply. Tailscale SSH is permitted based on your tailnet policy (who can SSH to which devices). ()
• Port 22 is the key detail. If you can SSH to the Kindle’s tailnet IP, the networking plumbing is at least partially working, and that helps narrow down failures later.

The three modes in the KUAL plugin: Standard, Proxy, Kernel TUN

On the Kindle, the KUAL environment (a Kindle interface for running scripts and plug-ins) becomes the control panel for Tailscale’s networking mode.

The community update exposes three modes:

1. Standard (Userspace)
2. Proxy Mode (SOCKS5 / HTTP CONNECT)
3. Kernel TUN (if supported) ()

Here’s the mental model:

• Standard (Userspace): the Kindle runs Tailscale in a way that may not let the rest of the OS transparently route to tailnet IPs.
• Proxy Mode: instead of relying on OS routing, Tailscale listens on local ports and applications connect to those local ports. The traffic is then forwarded through Tailscale.
• Kernel TUN: if the Kindle kernel supports it, Tailscale can behave more like a real network interface. Then applications can often reach tailnet IPs directly.

That “Kernel TUN (if supported)” caveat is the difference between a satisfying setup and a frustrating mystery.

Proxy Mode: making KOReader talk to the rest of your tailnet

Proxy Mode is the most immediately useful upgrade, because it works even when the Kindle can’t do true packet routing.

What KOReader needs: a proxy to reach tailnet services

In this setup, Tailscale (via its daemon, tailscaled, the process that actually manages the tunnel and routing behavior) runs a proxy endpoint on the Kindle, bound to the local loopback interface.

Loopback means 127.0.0.1—“this device, but only through the network stack.” It’s a safe place to expose a proxy because it isn’t reachable from the wider network unless something explicitly allows it.

The blog post describes this mapping:

• SOCKS5 proxy at 127.0.0.1:1055
• HTTP CONNECT proxy at 127.0.0.1:1056 ()

SOCKS5 vs HTTP CONNECT (plain English)

Both SOCKS5 and HTTP CONNECT are ways to ask a proxy to open a connection for you.

• SOCKS5 is a generic proxy protocol that supports many kinds of destinations.
• HTTP CONNECT is a special HTTP mechanism used to tunnel a TCP connection through a proxy. Many apps that speak “HTTP proxies” expect this exact style.

So the Kindle doesn’t need to understand your service (Calibre, Wallabag, OPDS, etc.). It only needs to understand “open a tunnel through Tailscale to a target IP.” ()

The connection flow: why proxy mode fixes the original failure

With proxy mode enabled, the flow becomes:

1. KOReader is configured to use the Kindle proxy at 127.0.0.1:1055 (SOCKS5) or 127.0.0.1:1056 (HTTP CONNECT).
2. KOReader asks the proxy to reach some tailnet IP like 100.x.y.z.
3. The proxy forwards that request through Tailscale via tailscaled.
4. Your other tailnet node receives the traffic, and KOReader gets its content.

In other words, KOReader no longer depends on the Kindle OS being able to route packets to tailnet IPs directly.

What you configure in KOReader

KOReader-style configuration tends to look like choosing a proxy address and entering host/port.

The key practical details from the community implementation are the local addresses and ports:

• Use 127.0.0.1:1055 for SOCKS5
• Use 127.0.0.1:1056 for HTTP CONNECT ()

Once KOReader routes through those ports, other KOReader features (RSS feeds, OPDS catalogs, server polling, and so on) can start working against devices that are otherwise unreachable.

What a proxied Kindle can actually do

When the proxy is working, the Kindle becomes a real client for the services you already host on your tailnet.

The original post lists some especially fitting targets:

• Calibre / OPDS-style libraries (books surfaced via an index)
• Wallabag (self-hosted reading list)
• Audiobookshelf connections through KOReader
• Readest for reading progress sync

And the “why not” ideas:

• lightweight internal web pages in the Kindle browser (though Kindle browsing is… its own personality)
• dashboards reached over Tailscale
• SSH-based terminal workflows through other apps (useful, but not always the smoothest path)

The common thread is that proxy mode turns “tailnet reachability” into “tailnet usefulness.” ()

KOReader-only option: a Tailscale plugin

If Tailscale powers are only needed inside KOReader (not as a general Kindle-wide networking layer), there’s another community project: a KOReader Tailscale plugin.

Conceptually, it does the same job as proxy mode—but scoped to KOReader workflows. Instead of relying on the KUAL plug-in modes, the KOReader plugin creates the proxy interface and helps KOReader talk to services through it.

This plugin ecosystem also splits proxy behavior across the same local ports:

• SOCKS5 proxy on :1055
• HTTP CONNECT proxy on :1056 (newreleases.io)

So the “right answer” can be either:

• KUAL + proxy mode when you want broader Kindle-side behavior
• KOReader plugin when KOReader is the whole point

Kernel TUN mode: the closer-to-native path (when supported)

TUN stands for a virtual network interface: a way for a VPN client to inject and receive IP packets as if it were a real network card.

With kernel TUN working, Tailscale can often route at the device level, which means applications don’t need to “remember” to use a proxy.

This is why the community calls it “Kernel TUN (if supported).” In Tailscale’s own broader documentation, kernel vs userspace networking affects whether the OS forwards packets through normal kernel routing or whether Tailscale instead exposes SOCKS5/HTTP proxy behavior. (tailscale.com)

On a jailbroken Kindle, “if supported” is everything: when the kernel module / interface behaves correctly, networking gets dramatically more intuitive.

A small troubleshooting checklist that saves hours

When anything doesn’t work, the failures usually fall into one of three categories.

1. Tailnet identity / reachability is broken
   - Verify the Kindle is connected on the tailnet admin console.
   - Use Tailscale SSH to confirm basic tunnel behavior (since port 22 routing is a good indicator). ()

2. App routing is wrong (proxy vs direct)
   - If in proxy mode, KOReader must point at the correct local proxy port.
   - A mismatch like using the HTTP CONNECT port with a SOCKS5 expectation can look like “network is dead,” even when Tailscale is fine.

3. Mode support limitations (Kernel TUN availability)
   - If kernel TUN doesn’t work on a given Kindle model/firmware/kernel combination, the setup may only behave correctly in Standard (userspace) or Proxy mode.

There’s also a general firewall footnote worth knowing: for typical Linux deployments, Tailscale uses UDP with a default port of 41641 for direct WireGuard tunnels (though you often don’t need to open ports). (tailscale.com)

On a jailbroken Kindle, though, most connectivity issues are more likely about networking mode and local proxy wiring than about your home firewall.

The real takeaway: treat the Kindle like a networking “special case”

A jailbroken Kindle isn’t just a small computer. It’s a small computer running in a liminal state—sometimes close enough to Linux to be useful, sometimes not.

Proxy mode is the breakthrough because it respects that reality: it gives applications a stable, local way to reach tailnet IPs even when kernel routing isn’t available. Kernel TUN mode is the bonus path for devices that can support it, where the Kindle can behave more like a normal network node.

And with Tailscale SSH enabled by default, debugging stops being an endurance sport.

Conclusion

The most satisfying part of this story isn’t that a Kindle can join a tailnet. It’s that the network behavior can be shaped into something real-world useful: SSH for maintenance, proxy mode for content flows, and kernel TUN when the device supports it.

Once you understand the difference between transparent routing and proxy-based connectivity, the whole setup stops feeling mystical—and starts feeling like engineering.