Connecting to a Challenge VPN

Some challenges — OffSec network attacks in particular — put their targets on a private range that is not reachable from the internet. You reach it through a WireGuard tunnel that the platform creates for you, per challenge and per player.

If a challenge needs a VPN, its page shows a VPN Access card. Everything below happens there.

What you need

The configuration is useless without the client, and the client does nothing without a configuration — you need both.

Step 1 — Install the WireGuard client

Use Get WireGuard client on the challenge page, or download it from the WireGuard project directly. Official clients exist for Windows, macOS, Linux, Android and iOS.

[!WARNING] Install WireGuard from the official project or from your distribution's package manager only. Fake "VPN client" installers are a common malware vector, and a tunnel client runs with enough privilege to matter. If a download link is not one you recognise, do not run it.

On most Linux distributions:

sudo apt install wireguard        # Debian / Ubuntu
sudo dnf install wireguard-tools  # Fedora

Step 2 — Get your configuration

On the challenge page, open VPN Access and click Get VPN credentials. The platform generates a fresh key pair and shows you:

• your VPN IP — the address you will have inside the range,
• the endpoint — the server your client connects to,
• a QR code, for the mobile apps,
• the configuration file, to download or copy.

Each click generates a new key pair. Your previous peer stays active until the challenge is deleted, so re-generating does not lock you out of a session you already have running.

Step 3 — Bring the tunnel up

Desktop app — open the WireGuard client, Import tunnel from file, select the .conf, then Activate.

Mobile — open the WireGuard app, add a tunnel, Scan from QR code, point it at the code on the page.

Linux command line — save the file and bring the interface up:

sudo cp ~/Downloads/wireguard.conf /etc/wireguard/ctf.conf
sudo wg-quick up ctf

Take it down again with sudo wg-quick down ctf.

Step 4 — Check you are on the range

sudo wg          # shows a recent handshake once the tunnel is really up
ping -c2 <the entry host shown on the challenge page>

A handshake with no reply to ping usually means the tunnel is up but you are aiming at the wrong address — re-read the endpoint on the challenge page. No handshake at all points at step 3.

Routing: all your traffic, or only the challenge?

The configuration you are given routes all your traffic through the tunnel (AllowedIPs = 0.0.0.0/0). That is the simplest thing that works, and it is what the mobile apps expect.

If you would rather keep your normal traffic outside the tunnel, edit AllowedIPs in the .conf to the challenge range only — the range is shown on the challenge page:

[Peer]
# instead of 0.0.0.0/0
AllowedIPs = 10.13.37.0/24

This is a client-side choice; the server accepts either.

Troubleshooting

No handshake. The endpoint is UDP. A network that blocks outbound UDP (some corporate and captive-portal Wi-Fi) will stop WireGuard cold, with no error other than silence. Try another network or a phone hotspot.

The tunnel is up but nothing responds. Confirm the challenge is actually deployed — a stopped challenge tears its range down. The challenge page shows its state.

It worked, then stopped. Deployed challenges expire. The page shows the expiry, and Redeploy brings the range back; you can keep your existing configuration.

Two challenges at once. Each challenge has its own tunnel and its own range. Keep one active at a time unless you have narrowed AllowedIPs on both — two full-tunnel configurations will fight over your default route.

For organisers

VPN access is provisioned per challenge, per player: each participant who clicks Get VPN credentials becomes a distinct WireGuard peer with its own address on the range. Nothing is shared between players, and revoking a challenge removes its peers with it.

The tunnel is part of the challenge deployment, so it follows the same lifetime as the rest of it — including the plan's event duration and the automatic stop after inactivity.