A Practical Walkthrough of a Surprisingly Hard Problem

For a task that sounded trivial at first, this experiment turned into a surprisingly deep dive into Android networking limitations, routing constraints, VPN behavior, and how Bluetooth Personal Area Networking (PAN) actually works under the hood.

My goal sounded simple:

Connect an Android phone to my Linux laptop over Bluetooth PAN and route ALL traffic from the phone to the Internet through the laptop — without Wi-Fi, without mobile data, without USB tethering, and without root.

Easy peasy.

What follows is a detailed, chronological walkthrough of everything I tried, from the obvious approaches to the ones that Android outright refuses, and the final solution that actually worked: using Tailscale as a VPN running on top of a Bluetooth PAN link.

This post is meant to be:

• technically accurate
• highly detailed
• fully reproducible
• and still enjoyable to read for other engineers who appreciate weird networking challenges.

Let’s begin.

1. The Setup and Initial Observations

The first step was straightforward: I enabled Bluetooth tethering (Bluetooth PAN) on my Android phone, connected it to my Linux laptop, and verified that the connection worked.

This part was surprisingly smooth:

• The laptop received a enx interface with an IP 192.168.44.34.
• The phone received the counterpart bt-pan interface with IP 192.168.44.1.
• I could ping from the laptop to the phone.
• And from the phone I could ping to the laptop (using Termux), and access a local HTTP server running on the laptop from the phone browser, confirming bidirectional connectivity.

So far so good: Bluetooth PAN was working as a local network interface.

But then came the real challenge.

2. The Real Goal: Routing the Phone Through the Laptop

The normal use-case of Bluetooth tethering is:

Laptop → Phone → Internet

But what I needed was the opposite:

Phone → Laptop → Internet

This breaks the default assumptions of Android:

• The phone wants to provide Internet via Bluetooth, not consume it.
• Android networking is extremely locked down.
• You cannot modify routing tables without root.
• Bluetooth PAN cannot have a proxy configured.
• And Android prioritizes Wi-Fi and mobile data interfaces aggressively.

So even though the PAN connection existed, Android had no idea it should use it as a gateway.

3. Attempt 1 — Modifying Android Routes via Termux (Fail)

My first idea was classic Linux networking:

ip route list
ip route add default via 192.168.44.34 dev bt-pan

…except Android does not allow this.

Inside Termux:

• ip rule list → Permission denied
• ip route → read-only
• Installing sudo → impossible
• Installing tsu → impossible (Termux could not access the Internet)

And of course:

Android prevents changing the default route without root.

This approach was dead on arrival.

4. Attempt 2 — Using a Local Proxy on the Laptop (Fail)

Thinking it was easy, I looked on Stack Overflow and Reddit and Android documentation, without results. Desperate on lack of ideas, I did the obvious thing I should have done on the first place: ask Google ChatGPT. It came up with a few ideas, that after restricting I needed to use a Bluetooth PAN connection, were reduced to two: use a proxy (quick and easy), and use a VPN (more complex).

The proxy idea was to expose it on the laptop using Python:

python3 -m http.server --bind 0.0.0.0 --cgi 8888

Simple, quick, and familiar.

The plan was:

• Phone uses laptop as an HTTP proxy
• Laptop forwards traffic to the real Internet

But here came another Android limitation:

Android does NOT allow setting a proxy for Bluetooth PAN connections.

Proxy configuration is only available for:

• Wi-Fi networks
• Mobile data (in some OEMs)
• VPNs

But not Bluetooth, at least with OEMs images (CyanogenMod was like a theme park for these kind of hacks).

So even though I could serve files to the phone using the laptop, I could not tell the phone to use the laptop as a gateway via a proxy.

Another dead end.

5. Attempt 3 — Setting Up a Custom OpenVPN Server (Rejected)

The next ChatGPT idea was:

“What if we run a VPN server on the laptop and make Android send everything through it?”

Totally possible in theory:

• Run OpenVPN/WireGuard on the laptop
• Import config on Android
• Force all traffic through the tunnel

However:

• I would need to generate certificates
• Copy them to Android
• Prepare .ovpn files
• Configure firewall routes
• Enable forwarding
• And troubleshoot everything by hand

Given the time constraints and operational complexity, this was too heavy and error prone.

I needed something cleaner.

6. The Breakthrough — Leveraging Tailscale

At this point I remembered that:

• I already had Tailscale VPN installed on both the laptop and the phone from a previous experiment
• Tailscale supports Exit Nodes (I didn’t know that, I planned to use old school Linux routes, but later this came handy)
• And more importantly… Android routes all traffic through any enabled VPN by default

That last point is critical.

When a VPN is active, Android does:

default route → VPN interface

regardless of the physical interface underneath.

And suddenly everything clicked.

If I activate Tailscale on the phone, it will prefer the VPN endpoint as its default gateway. If the laptop is configured as an Exit Node, it will become the phone’s route to the Internet. The only remaining question is: will Tailscale connect over Bluetooth PAN?

Spoiler: yes. Perfectly.

7. How Tailscale Behaves in This Scenario

I activated airplane mode, removed the SIM card, and only re-enabled Bluetooth.

The phone now had exactly three network interfaces:

• lo
• bt-pan (192.168.44.1)
• tun0 (Tailscale, something like 100.x.y.z)

No Wi-Fi. No mobile data. No cellular modem. No other paths.

I activated Tailscale and selected my laptop as the Exit Node.

Tailscale did something beautiful:

It detected the laptop as a LAN peer (Bluetooth PAN counts as LAN!) and established a direct tunnel entirely through the PAN link.

Now Tailscale traffic flowed like this:

Phone → Tailscale client → bt-pan → Laptop → Tailscale Exit Node (Laptop itself) → Internet

And because the VPN is the default route on Android:

Everything → Tailscale → Laptop → Internet

8. Verification and Testing

To ensure absolutely no traffic leakage, I removed the SIM and stayed in airplane mode.

Then:

✔ Ping from laptop → Android (via PAN)

Working (192.168.44.1).

✔ Ping from laptop → Android (via Tailscale IP)

Working (100.x.y.z).

✔ Ping from Android → 8.8.8.8

Working perfectly.

✔ Accessing laptop-hosted HTTP servers

Android could browse:

http://192.168.44.34:8000/

with Python serving on the laptop.

✔ Browsing the Internet on the phone

Successful request to example.com.

Everything was working exactly as intended:

• Local access via PAN
• VPN routing via Tailscale
• Internet access routed through the laptop
• Completely isolated, no Wi-Fi or mobile data involved

9. Why This Works (Short Version)

This solution works because:

1. Bluetooth PAN provides a functional IPv4 LAN interface.
2. Tailscale uses whatever network link is available, including PAN.
3. Android automatically sends all traffic through VPNs.
4. The laptop advertises itself as a Tailscale Exit Node.
5. The laptop has real Internet access and NATs packets for the phone.

It is effectively:

A full VPN tunnel running over a Bluetooth PAN connection, with the laptop acting as a router.

No root. No route hacks. No USB. No Wi-Fi. No SIM card.

10. Final Thoughts

This turned out to be a much more interesting experiment than expected. What started as a simple “reverse Bluetooth tethering” problem became a practical demonstration of:

• Android network constraints
• Tailscale’s smart peer discovery
• How VPN default routing works on Android
• The flexibility of Bluetooth PAN as an IP transport
• How creative layering of tools can solve non-standard networking needs

The final result is solid, reproducible, and useful for engineering contexts where devices must operate without Wi-Fi or mobile data, but still need controlled and monitored Internet access.

It’s also a great little example of how sometimes the simplest network tunnel becomes available only after exploring every other dead end. Maybe one day I’ll try to do it with OpenVPN directly to don’t depend on third party companies.

Not today.

Note

This post was developed collaboratively between me and ChatGPT GPT-5, an AI language model by OpenAI. The ideas, discussion, and final decisions were shaped through a process of interactive brainstorming and refinement. After that, final formatting and edition was done by hand. You can download a detailed discussion of the process.

#human-ai-collaboration