Which Login Failed: eduroam Access or the VPN?
Joining eduroam is access-network onboarding; joining a VPN is a separate relationship. Decide which login actually failed before anyone changes a port.
Two logins sit behind the sentence "the VPN does not work on eduroam", and different teams own them. Joining eduroam gets the device onto an access network; joining a VPN builds a second relationship on top of that connection. Both may be run by the same institution, yet the credentials, the profile and the stage where things break stay separate. Work out which of the two actually failed before anyone edits a port number. Everything below is organised around that one fork.
One campus where OpenVPN answered on UDP 1194 is useful history, not a recipe for the next one.
Prove the access side first
Turn the tunnel off and load a plain HTTP page or a captive portal. If it opens, the access network is doing its job and the VPN question is genuinely open. If nothing loads, the fault sits in the association, the account or the onboarding profile. No change to the VPN will touch any of those three.
The eduroam connection guidance makes the home institution the source of the user's identity. When a configuration assistant builds a profile, choosing the visited institution rather than the home one produces a setup that cannot authenticate. Use whatever onboarding the home institution publishes instead of a certificate bundle from somewhere else.
Switching off a certificate or authentication check to get past a login turns a fixable misconfiguration into a permanent one. If the installed profile came from an unapproved source, replace it before troubleshooting anything else.
Who owns which failure
Once access works, every remaining question has exactly one owner. This is the whole division:
| Owner | Questions that belong to them |
|---|---|
| VPN operator | Server name, protocol, transport, port, client compatibility, VPN authentication |
| Visited network operator | Which traffic the local arrangement permits, and any observed path problem |
| Device or client administrator | Local policy, client build, server-identity errors |
The transport row is where most do-it-yourself attempts fail. What the server listens on is fixed in its configuration, and editing the client profile cannot change it, so ask the operator for the current profile rather than toggling TCP and UDP. Toggling only changes the way the client fails.
On the visited side, a successful eduroam authentication says nothing about whether that path carries a given VPN transport, and a timeout alone is not evidence of blocking. Both claims get made daily, and each one needs an observation behind it.
On the device side, a managed security rule, an incompatible client build and a server-identity error are three different faults. Bundling them into a single ticket slows all three down.
Choose the evidence before the theory
Where the profile is yours to test and the operator has approved it, one comparison beats an argument: does the same profile connect from another trusted network? A yes points at the visited path, a no points at the profile, the server or the client. Run that test inside the rules that apply to the account, and never by installing a client nobody approved.
If the operator publishes an approved alternative profile, use it. Inventing a listener on a new port or loosening the network's rules produces a result nobody can defend later, and it hides the original fault.
Write the result in the form the three owners can act on, not the form that is quickest to type. A bare timeout tells the VPN operator nothing useful, and an authentication failure tells the visited network operator just as little.
One log line often settles it. TLS Error: TLS key negotiation failed to occur within 60 seconds points at the path or the port, while AUTH_FAILED means the tunnel was reached and the credentials were refused.
Write the handoff in five lines
A concise handoff carries five things: the visited location, the attempt time, the approved client version, the server and transport the profile pointed at, and the earliest informative error. Add whether ordinary access worked, and whether an approved cross-network comparison was made, if you have those two. Redact passwords, tokens and private keys before it leaves your desk.
If the VPN authenticates and a private application then fails, pass that later result onward on its own. Both earlier questions are answered by then, and folding them into a fresh "still broken" report sends everyone back to the beginning.
Five lines, three owners, one fork: that is the whole decision, and it is usually settled before anyone touches a port number.