Ping documentation

Quick start

1. Ask your administrator for a connection key — a single line starting with ping://v1?.
2. Download the Windows client and install it (administrator rights required).
3. Open Ping, paste the key, and press Connect.

Windows client

The Ping client is a native Windows app. On connect it opens a Wintun adapter, performs the 1-RTT handshake, and routes your traffic through the tunnel.

• Profiles — each pasted key becomes a saved profile you can rename and switch between.
• Autostart — optionally launch Ping and connect the last profile at sign-in.
• Connection log — every connect, disconnect, and roam is recorded locally with timestamps.
• Update check — the app checks for new versions and points you to the download.

Split tunneling

Split tunneling decides which traffic uses Ping and which goes direct. Two modes:

• Include — only the apps and domains you list use the tunnel; everything else is direct.
• Exclude — everything uses the tunnel except the apps and domains you list.

Rules can target applications (by executable) or destinations (by domain or IP range). Changes apply on the next connect.

PING/1 protocol

Ping is an original protocol — not a fork of WireGuard, OpenVPN, or IPsec. It defines its own packet format, handshake framing, multiplexing, and roaming, built on vetted cryptographic primitives rather than new cryptography.

Packets carry a 4-byte type header; everything after it on a data packet is ciphertext. A packet failing the mac1 check is dropped silently, so the endpoint does not respond to scanners.

Multiplexing

One session carries several logical channels: raw IP (channel 0), control (1), and a DNS fast-path (2). Frames coalesce into a single MTU so a slow lookup on one channel never blocks bulk data on another.

Running a server

The server is a single Go binary. It owns a UDP socket and a TUN device, terminates client sessions, and NATs their traffic to the internet. It must run as root (for the tunnel adapter and routing).

# build
go build -o ping-server ./server/cmd/ping-server

# run (root) — creates the ping0 device, enables NAT, listens on udp/51820
sudo ./ping-server -host ping.kwezert.com

Server identity and settings live in a SQLite database shared with P-panel. On first run the server generates a stable static keypair and writes sensible defaults.

P-panel reference

P-panel manages users, keys, connections, statistics, and settings. Run it with no arguments for the interactive panel, or use subcommands for scripting.

ppanel                              # interactive panel
ppanel user add alice --days=30     # create a user, print its key
ppanel user list                    # all users
ppanel user disable alice           # revoke without deleting
ppanel user del alice               # remove a user
ppanel conns                        # live connections
ppanel stats                        # traffic summary
ppanel log 50                       # recent events
ppanel set endpoint_host vpn.example.com
ppanel settings                     # show server settings

Creating a user generates its keypair and PSK, allocates a tunnel address, and prints the ready-to-paste ping:// key. The server picks up new and revoked users on the next handshake — no restart needed.

Key format

A connection key is ping://v1? followed by URL-safe base64 of a small JSON object:

{
  "h": "ping.kwezert.com",   // endpoint host
  "p": 51820,                 // endpoint UDP port
  "s": "<server public key>",
  "k": "<your private key>",
  "P": "<optional pre-shared key>",
  "a": "10.13.37.5/32",       // assigned tunnel address
  "d": "10.13.37.1",          // pushed DNS
  "n": "alice"                // friendly name
}

The private key and PSK exist only inside this string and on your device; the server stores only the matching public halves.

FAQ

Does Ping invent its own encryption?

No. Inventing new cryptography is how VPNs get broken. Ping defines an original protocol on top of standard, vetted primitives (X25519, ChaCha20-Poly1305, BLAKE2s).

Why UDP?

A VPN carries datagrams. Running the tunnel over UDP avoids TCP-over-TCP meltdown and keeps latency predictable under load.

What happens when I change networks?

Nothing you'll notice. Sessions are identified by index, not IP, so your tunnel keeps working from the new address as soon as the first packet authenticates.