Why Android IKEv2 Fails on a Nonstandard UDP Port

The gateway answers IKEv2 on UDP 4443 for a reason, the profile has a field labelled Server, you type the hostname and the port, and the phone reports that it cannot reach the server or cannot resolve the address. Nothing is being blocked. The native Android form expects a host, and the same is true on Windows. A custom port is a client capability before it is a server setting, and only some clients let you express it. Work through the three parts in order: what the client can say, what the server is listening on, and whether both ends frame the packets the same way.

What the phone actually sent

A host:port string in a field designed for a name is resolved as a name. The resolver returns nothing for vpn.example.net:4443, and the error you see is a name-resolution or unreachable failure rather than a timeout on a port. That distinction matters, because retrying with a shorter name or a different network will never fix a string the form cannot parse.

The native IKEv2 profile on Android, like the built-in Windows VPN client, is fixed to the standard IKE ports. Neither exposes a port field, and no amount of profile editing adds one. If the operator's listener really is on 4443, the built-in client is the wrong tool, not a misconfigured one.

Use a client that exposes the port

The strongSwan Android client documents a configurable server port in its advanced profile settings, which is why it appears in almost every working recipe for this design. That support belongs to that client: another IKEv2 app, or a vendor fork of the same app, may not expose the same field even though the underlying strongSwan daemon supports it.

Ask the operator for the whole set at once: gateway name, UDP port, authentication method, and the server identity the client must expect. A custom port is not a reason to disable certificate checking or to switch protocols. Enter the port where the installed client expects it, and if that client has no such field, the answer is a different approved client rather than a guessed workaround.

The server has two ports, and both must match

IKE starts on UDP 500, and NAT traversal usually moves IKE and encapsulated ESP to UDP 4500. Those are separate settings in strongSwan, so a server moved to a single custom port needs both changed to the same value:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

With one port for both roles, the daemon has to tell IKE apart from ESP-in-UDP on that same socket, which it does by the four-byte non-ESP marker that precedes an IKE message. That is why a client cannot negotiate on the custom port and then silently continue on 4500, and why the phrase "just change the port" hides a framing requirement.

A forward is not a listener

Forwarding 4443 to an ordinary IKE listener is the failure mode that looks almost successful. The first exchange arrives, the server answers, and the connection then stalls or rekeys into nothing, because the reply leaves from a different port and the later encapsulated traffic never matches the state the two ends created. A rule that rewrites the destination port without moving the listener produces exactly this half-open result.

The path also has to allow UDP end to end. Passing TCP 443 through a hotel or carrier network says nothing about IKEv2 on a UDP port, even one with the same number. Where only TCP 443 is permitted, a custom UDP port does not turn IKEv2 into HTTPS, and the correct answer may be a different access path rather than another port experiment.

Separate the three stages when you test

Capture on the server while the client tries once. A request that never arrives is an endpoint or firewall question; a request that arrives with no reply is a listener or policy question; a reply that is followed by silence is the framing or identity question.

tcpdump -ni eth0 -vv udp port 4443

Then read the client's message rather than its spinner. A proposal error means the algorithms disagree, an authentication failure means identities or certificates disagree, and repeated retransmissions with no response mean nothing is answering on that port. Test one stage at a time and change one field between attempts; the strongSwan documentation on NAT traversal describes the marker and port behaviour the capture is showing you.