Old Phone as a VPN Gateway: Three Conditions to Check
An old phone is only an appliance if the role is supported, the network can reach it, and someone owns recovery. Three conditions, one decision.
A drawer phone has a processor, flash storage, Wi-Fi and a battery, which is more hardware than most single-board computers people happily deploy. It also has a screen, an ageing battery and an OS that stops receiving patches when the vendor moves on. None of that decides whether it should become a VPN gateway or a NAS.
Whether it should become a VPN gateway or a NAS is not settled by that comparison, because the comparison is about capability and the decision is about operation.
Three conditions decide it. If any one fails, the project is a weekend experiment rather than an appliance, and it is better to know which condition failed before you migrate data onto it.
Condition one: the role is actually supported
Three arrangements get called the same thing. A VPN client protects traffic from apps on the phone. A VPN server accepts inbound connections. A gateway forwards other devices' traffic into a tunnel. They are different projects, and a working client tunnel proves nothing about the other two.
An application on stock Android is subject to background execution rules, and a terminal left open is not a daemon. The platform's own Doze and App Standby guide describes why a background process may lose network access when the device decides to idle, which is exactly the behaviour you cannot have in a gateway.
A Linux userspace inside Android inherits more constraints than it removes. A chroot changes the filesystem root while still running on Android's kernel, its drivers and its security policy, so root inside the chroot is not root over the platform. Replacing the OS instead makes modem, storage and power support for that specific handset part of your project, and handset support is usually the part nobody maintains.
Condition two: the address is reachable
A gateway needs to be reachable by the clients that depend on it. A phone on Wi-Fi inside a home router is reachable from that LAN and from anywhere the router forwards, but not from the internet unless you arrange it.
Cellular makes this harder rather than easier. Many mobile networks place subscribers behind carrier-grade NAT, so there is no inbound address to forward to at all, and adding a modem does not create a public listener. If the requirement is remote access from outside, the design has to include a relay or an overlay network that both ends connect outward to, and that is a second moving part to maintain.
Network attachment also varies by device. Some phones accept USB Ethernet adapters, some do not, and Wi-Fi adds its own latency and roaming behaviour. A gateway that sleeps when the screen is off or drops the tunnel during a handover is worse than no gateway.
Condition three: someone owns updates and recovery
This is the condition people skip, and it is the one that decides whether the thing survives a year. Every component needs an owner: the OS build, the kernel if you replaced it, the server package, the certificates, and the credentials you handed out.
Recovery is the harder half. How do you get in after a reboot with no screen, a broken touch panel, or a swollen battery? How do you revoke a lost client identity? How do you restore the storage onto a replacement device when the original is a discontinued model?
Power belongs here too. Sustained load means sustained heat, and an ageing battery is not an automatic UPS. Follow the manufacturer's guidance, and treat any swelling or damage as a stop signal rather than something to work around.
When the answer is no
Run the three conditions against what you actually need, and be specific about the task rather than the category.
| Task | Phone is reasonable when |
|---|---|
| Protecting the phone's own traffic | The client is a supported Android app; no forwarding involved |
| Small lab tunnel inside one LAN | Downtime is acceptable and you can reach the device to fix it |
| Household NAS holding the only copy | Never; that is a backup problem, not a hardware problem |
| Unattended remote access for others | You already own patching, revocation and replacement |
A dedicated Linux host does not escape the list either. It has a clearer service manager, storage and network administration path when the hardware and distribution are supported, but it still needs power, updates and backups. The board alone is not an appliance.
So choose the phone when its supported capabilities fit a modest task and experimental downtime is genuinely acceptable. Choose something else when the requirement is household storage that must not be lost, or remote access that other people will depend on. In both of those cases the deciding factor is a reproducible installation and a recovery procedure you have actually tested, and no amount of free hardware substitutes for either.