Android VPN to Cisco IOS: the Contract to Get First

The phone needs to reach a Cisco gateway. Someone has already named the client to install. That is the wrong end of the process, and it is why the tunnel fails after an hour of retyping credentials.

What you need first is a connection contract: protocol, authentication, identity, trust material, address assignment and routing, written down by whoever runs the gateway.

Get that in writing and the client choice becomes a lookup. Skip it and every failure looks like a bad password.

Run the intake before you install anything

Send the gateway owner a list and ask for answers, not a product name. Nine items cover a remote-access profile completely:

1. Gateway hostname or address the client should dial, and whether it is reachable from outside.
2. The protocol and version: IKEv2, another IPsec generation, or a TLS-based service.
3. The peer identity the gateway expects, and what it presents back.
4. Trust material: which CA signs the gateway certificate, or whether a pre-shared key is used.
5. User authentication: certificate, EAP username and password, or a pre-shared key.
6. The address pool the client lands in, with mask and gateway.
7. DNS servers to use inside the tunnel, and whether the client must accept them.
8. Permitted destination prefixes, and whether traffic outside them must be blocked.
9. The supported client releases and phone OS versions, plus any enrollment requirement.

Two of those items cause most of the avoidable failures. Without the trust material you cannot validate the gateway, so a correct client looks broken. Without the permitted prefixes you cannot tell a routing restriction from a service problem.

The vendor name is not a protocol

Cisco IOS and IOS XE offer several remote-access arrangements, and they do not share a wire format. IKEv2 with a FlexVPN-style profile is not the same service as an older IKEv1 configuration, and a TLS-based client service is a different product again, often on a different platform in the same estate.

So a client whose name mentions the router vendor proves nothing. It may implement one of those services well and none of the others. Ask which service is configured, then check that the client's documentation names that service as supported.

Cisco's own IKEv2 documentation separates the proposal, policy, profile and keyring as distinct objects. That structure is useful when you are reading a configuration someone pastes at you: it tells you which object holds the settings that matter for a remote phone, instead of treating the whole file as one blob.

What Android's built-in stack covers

Android exposes a platform IKEv2/IPsec profile through Ikev2VpnProfile, with separate authentication types for a pre-shared key, an RSA certificate, and EAP username and password. The Ikev2VpnProfile reference is the authority on what the builder accepts, including the gateway hostname and the server root CA used to validate it.

That API is a capability statement, not a compatibility promise. It says the platform can do IKEv2 with those authentication types. It does not say a given OEM Settings screen exposes every field, nor that a profile file exported from another product will import.

It also means the built-in stack will not save you if the gateway is running a service the platform does not implement. In that case you need the vendor client the operator supports, installed and configured as the operator documents, rather than a workaround built on a protocol the phone does not speak.

Test in the order the contract is written

Validate one layer at a time and stop at the first failure, because later tests are meaningless until the earlier ones pass.

Trust. If the client rejects the gateway certificate, nothing else matters. Confirm the CA you were given signs the certificate the gateway presents, and confirm the hostname you dialled appears in it. Keep validation on; disabling it converts an identity problem into an interception risk.

Authentication. A rejected credential and a mismatched proposal produce different errors but similar-looking failures. The gateway log is the tiebreaker: it will say whether the proposal was acceptable before it says anything about the user.

Address and DNS. Confirm the phone received an address from the documented pool, then resolve one internal name. A tunnel that comes up with an address and no resolver looks connected and behaves as if nothing works.

Reachability. Test one permitted destination by address, then by name. If the address works and the name does not, you are back at DNS. If neither works, compare the prefix you are testing against the permitted list before touching the client.

Failure modes and the rollback

Keep the previous working profile exported and documented before you change anything, including the CA alias and the address pool. Rollback then means restoring a known profile, not reconstructing one from memory during an outage.

When it works, record the nine intake answers next to the profile. The next phone, the next OS update, and the next gateway change all become a comparison against a document instead of another afternoon of guessing.