Testing a server's configuration Pro¶
Two buttons on Customers → (customer) → Integrated Server tell you whether a VPN server is really going to work, without waiting for a user to complain.
| Button | Where | Answers |
|---|---|---|
| Check ports | Server status panel | Is every port I need actually open? |
| Run test | Full configuration test card | Will this server carry traffic once a client connects? |
Check ports¶
The Server status panel lists every inbound port the VPN host needs, what protocol it is, and — importantly — who has to be able to reach it:
| Port | Protocol | Must be reachable from |
|---|---|---|
WireGuard® port (e.g. 51820) |
UDP | VPN clients, i.e. the public internet |
| Fallback port, if enabled | UDP | VPN clients, i.e. the public internet |
Health port (e.g. 9004) |
TCP | VPN clients, i.e. the public internet |
Management port (e.g. 9003) |
TCP | Your Valenius backend only |
Click Check ports to test each one and get a coloured result.
The management port is not a public port
It is how your backend administers the server, and nothing else needs it. Never open it to the whole internet. If your backend reaches the VPN host over a site-to-site VPN, you don't need to open it at all. If it doesn't, the panel shows your backend's public IP address so you can allow just that one address.
What the results mean¶
Open — verified. For the two TCP ports this is a successful connection. For the UDP ports it means a complete WireGuard® handshake succeeded, which is much stronger: the port is reachable, the server is genuinely WireGuard®, and it accepted a brand-new peer.
Blocked — nothing accepted a connection. Check the firewall and, if the host is behind NAT, the port forwarding.
Port open, no answer (management port only) — the firewall is fine, but the sidecar isn't answering. Check the container is running and enrolled.
No rejection (UDP, amber) — only shown when a full handshake wasn't possible. It means "nothing actively refused us", which is what an open port looks like and what a firewall silently discarding packets looks like. It is not a pass. Connect the sidecar to get a real answer instead.
Tested from the backend, not from a client
Everything is checked from your backend's network position. If your backend is allowed through a firewall that blocks everyone else, these checks can pass while your users still can't connect.
Run test¶
The Full configuration test goes further and covers the half a port check can never see: whether the host will actually forward the traffic once a tunnel is up.
It does two things:
- Reachability — performs a real WireGuard® handshake from your backend, using a temporary peer that is deleted again immediately. A success proves the port is reachable, the server's key matches what the backend has on record, and peer provisioning works end to end.
- Server self-check — asks the server to inspect itself: interface up, listen port matching its config file, IP forwarding, NAT, firewall forwarding rules, an upstream route, and whether its running peer list still matches its config file.
Nothing is changed permanently, and the temporary peer is always removed. If it ever can't be removed, the panel tells you the exact key to delete by hand.
Reading the result¶
Each self-check row is pass, warn or fail.
- fail — something is definitely wrong and clients will be affected.
- warn — worth knowing but not currently breaking anything. For example, no explicit firewall forwarding rules while the default policy still allows forwarding: it works today and breaks the day someone tightens the policy.
A green handshake alone is not a healthy server
The two halves answer different questions. IP forwarding disabled or a missing NAT rule produce the most confusing failure in VPN troubleshooting: the tunnel connects perfectly, shows as connected, and carries no traffic at all. Only the self-check sees those.
If the self-check says "not checked"¶
The self-check needs a recent sidecar image. On an older server the panel says so and warns that the test was only half completed — the reachability result above it is still valid, but forwarding and NAT were never verified. Update the sidecar image on that host to get the full picture.
Optional: fallback port¶
Some networks — hotel and guest Wi-Fi, restrictive corporate egress rules — block the high UDP port WireGuard® normally uses, while leaving UDP 443 open because ordinary web browsing uses it.
On Server settings → Connection you can switch on Answer on a fallback UDP port. The server then answers on that port in addition to its normal one — both stay live. A Trigger after (seconds) field (default 20) controls how long a client waits with no confirmed connection on the normal port before it tries the fallback once — purely client-side timing, it saves instantly with no effect on the server itself.
What this does and doesn't do today
Enabling it makes the server reachable on the second port, and Run test will confirm that with a real handshake. The Windows and Android clients switch to it by themselves when the normal port seems blocked. Linux, macOS and iOS don't yet — that's coming in a later release for each. Until those ship, this is still useful for preparing a server in advance, and for anyone on those platforms connecting with a manually adjusted configuration.
When a Windows or Android client's connection does switch, it's visible in two places: the app shows which port the connection actually ended up on (e.g. "Verified · 443" on the profile row/tray), and the client's History tab logs a "Fallback port" event.
Remember to open the fallback port on the firewall too — it appears in the port list once enabled.
This is UDP 443, not the TCP 443 that websites use
It helps on networks that filter by port number. It does not help where all UDP traffic is blocked.