Android OpenVPN: add a private route without rooting the phone

You need one more private subnet — say 10.60.0.0/24 — that the profile does not currently include. On a laptop you would add a route and move on. On Android the VPN is an app, the tun device belongs to that app, and there is no routing table for you to edit without root. The route still has to exist, but it goes into the profile the client loads, and it only works if the far side agrees. Here is the edit, the reconnect, the server side, and the rollback.

Before the edit: what a route can and cannot do

A route answers one question: which interface should carry traffic for this destination. It does not authorise anything. If the network owner has not agreed that this phone may reach that subnet, a correct route produces a correct-looking config and a silent drop at the gateway, and you will spend the next hour editing the wrong file.

Get that agreement first, in writing if the network has an owner. Then note what you are not doing: you are not assigning the phone an address inside that LAN, not changing the server's listener, and not selecting a site by hostname. Those are four different changes and only the first one is yours.

Edit the profile the client actually loads

For a compatible client that imports ordinary OpenVPN option text, the addition is one line:

route 10.60.0.0 255.255.255.0

Add it to the profile body, near the other routing directives, keeping the operator's endpoint, certificates, key handling and verification lines exactly as they were. Do not paste in a whole old example to borrow one line: compression, absolute file paths and obsolete cipher settings travel with it and will cost you a separate debugging session.

The step people miss is the ownership of the file. If the app imported a profile, the copy it uses is the app's, and editing the downloaded original changes nothing. Use the client's supported editor, or re-import the edited file through the update path, and confirm the active profile's name when several similar names exist. Record which one you changed.

If the profile already carries route-nopull, no route from the server is installed and every prefix the phone needs must be listed explicitly. That is a legitimate design, but it means an omitted line looks exactly like a server refusal.

Reconnect and verify on the device

Disconnect first, then reconnect the specific profile you edited rather than letting the app restore the last session. Open the connection log and confirm the client parsed the new line; a route directive that the frontend ignores is a common outcome of editing the wrong copy.

Test the destination by address, not by name. A TCP check to one known service port is more informative than a ping, because plenty of hosts answer ICMP while the service port is filtered. If the address answers and a name does not, you have a resolver question rather than a routing one, and the next section is not for you.

Two scope checks belong here as well. Per-app VPN means an address route can be present while the app you are testing with is outside the included set, so test with an app that is actually inside. And an IPv4 prefix says nothing about the IPv6 path; if the service is dual-stack, add the corresponding IPv6 route or expect the client to prefer a path you did not intend.

One negative result is worth recognising early: if a full-tunnel route already covers 0.0.0.0/0, the prefix is not missing and adding it again changes nothing. Duplicate coverage does not repair a server-side denial or a missing reply.

Finish the path on the server

Three things must be true beyond the phone. The gateway needs a route to the destination and permission to forward the phone's source toward it. The target needs to accept that source and return replies through the gateway, or the design needs deliberate translation on the egress. The OpenVPN manual's route option covers the client-side directive; forwarding and return routing are separate settings on separate machines.

If the destination sits behind another VPN client rather than directly behind the gateway, the server needs an iroute for that peer's subnet. That directive is server-owned and describes which client owns a prefix; a phone cannot supply it from its own profile, and no amount of client-side editing substitutes for it.

Check the return path explicitly. A reply that leaves by the default route instead of the tunnel produces the classic half-open symptom: the connection is established in one direction and nothing comes back. Source translation on the gateway is a legitimate fix when the target cannot route back, but it is a policy decision with its own consequences.

Rollback and acceptance

Keep the previous profile before you edit it. If the change makes things worse, restore that copy through the same re-import path, reconnect, and confirm the old behaviour returns — that confirms you changed what you thought you changed. A rollback that does not restore the old state means the app is holding a third copy you have not found.

Accept the change when four things hold, tested in this order after a fresh reconnect: the destination answers on its service port, the private name resolves if one is expected, HTTPS still validates the intended hostname, and the whole thing still works after a reboot or a Wi-Fi to cellular switch. The last check is the one that catches a route that only exists until Android re-establishes the tunnel.

• Confirm the network owner allows the destination before editing anything.
• Put the route in the profile the client loads, then re-import and reconnect.
• Verify by service port, inside the per-app scope, for the right address family.
• Fix forwarding, return routing and iroute on the server, not on the phone.
• Keep a rollback copy, and re-test after a reboot.