Reading an ALightVPN Connection Log: Handshake, Timing and Statistics

What was tested

Client profile was used with the installed OpenVPN 2.7.0 Windows client (git build v2.7.0/ee1577744fb09af7), reporting OpenSSL 3.6.1, LZO 2.10 and Windows build 10.0.26300, amd64. The profile specifies UDP port 1194, TLS minimum 1.3, SecP384r1MLKEM1024, data-cipher preferences CHACHA20-POLY1305:AES-256-GCM, tls-crypt-v2 and disabled data-channel offload.

The test temporarily raised verbosity from 0 to 4 and wrote one-second status snapshots. It used dev null, route-noexec, route-nopull and a DNS-option filter, so no real tunnel interface carried user traffic. Certificate checks and the required hybrid group were retained. The diagnostic process was set to stop after 15 seconds of tunnel inactivity, with a 40-second collector ceiling; all three exited normally before that ceiling.

This is one client, one profile and one endpoint tested three times sequentially. It is not an audit, a platform-wide compatibility result, a comparison against classical key agreement, or a test of routed browsing, DNS resolution through the VPN or leak prevention. The endpoint, certificate subjects, session identifiers and private profile material have been removed from the published evidence.

Measured times and how to read them

Every value in this table starts at the collector’s monotonic clock immediately before launching OpenVPN. The event time is when the collector receives that log line. Startup, network round trips, certificate work, buffering and scheduling are included. Values are rounded to milliseconds for readability; the extra digits in the download do not establish microsecond measurement accuracy.

The selected-group summary arrived in 0.359 s–0.428 s, with a median of 0.380 s. Initialization completion ranged from 4.813 s to 5.831 s. Three observations are a small sample, not a general latency promise.

The original machine-readable logs begin with an epoch timestamp and a message-flags field. Keep differences within one clock domain: subtracting two original log timestamps is different from subtracting two collector receipt times. Their absolute clock alignment and effective resolution are not assumed to be identical. Launch times above use IST (UTC+05:30); the JSON also records UTC.

A real log, line by line

The following is an allowlisted excerpt from run 1. The leading elapsed time is the collector receipt time. Original timestamp/flags prefixes are omitted in this excerpt for readability and retained in the downloadable text; redaction markers replace identifying details.

+0.031s    route_delay = 5
+0.183s  TLS: Initial packet from [AF_INET][VPN endpoint]:1194, sid=[redacted]
+0.276s  VERIFY OK: depth=0, [certificate subject redacted]
+0.359s  Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer signing digest/type: rsa_pss_rsae_sha256 RSASSA-PSS, key agreement: SecP384r1MLKEM1024
+0.442s  PUSH: Received control message: [server options redacted]
+0.442s  Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
+0.442s  Options error: option 'route-ipv6' cannot be used in this context ([PUSH-OPTIONS])
+0.442s  Data Channel: cipher 'CHACHA20-POLY1305', peer-id: [redacted]
+0.442s  Timers: ping 10, ping-restart 120, inactive 15
+5.309s  TEST ROUTES: 0/0 succeeded len=0 ret=1 a=0 u/d=up
+5.309s  Initialization Sequence Completed
+15.758s  Inactivity timeout (--inactive), exiting
+15.759s  SIGTERM[soft,inactive] received, process exiting

Why initialization appears about five seconds later

In run 1 the data-cipher summary appeared at 0.442 s, while initialization completed at 5.309 s: a gap of 4.866 s. The same trace explicitly reports route_delay = 5, route_delay_defined = ENABLED and a later TEST ROUTES event immediately before completion.

This is consistent with the client’s configured route-delay/readiness path and scheduling; it is not evidence that ML-KEM computation took five seconds. The configured delay and the observed gap need not match exactly, and this capture does not isolate the implementation’s timing internals. We did not run a route-delay-zero comparison or a pure cryptographic microbenchmark.

The pushed redirect-gateway and route-ipv6 messages also appear as Options error lines. They occurred in the deliberately restricted push context of this route-isolated test. The trace continued to a selected data cipher and completed initialization. These lines are disclosed rather than treated as successful route installation or as a failed hybrid handshake.

Byte counters, keepalives and the planned exit

Each latest snapshot recorded 6,059 transport bytes read and 6,215 written, with zero TUN/TAP bytes in either direction. “TCP/UDP” is OpenVPN’s generic counter label; this profile used UDP. These are the client’s transport counters for the diagnostic interval, including protocol/control traffic, not useful download/upload payload or a complete packet-capture accounting of link/IP overhead. Do not add read and write bytes and present them as application throughput.

The Auth read bytes counter was 16 in each snapshot; it is an internal status field, not a count of logins, authentication attempts or user requests. The snapshots are collected at intervals and can precede final process termination. Full process durations, including startup and shutdown, were 15.804 s, 16.060 s, 15.492 s.

Timers: ping 10, ping-restart 120, inactive 15 describes OpenVPN keepalive/restart/inactivity settings, not measured ping latency. Internal keepalives and TLS control packets do not count as user activity for this inactivity rule. Inactivity timeout (--inactive), exiting followed by SIGTERM[soft,inactive] was therefore the expected diagnostic stop, not a crash or a failed certificate check. Each process returned exit code 0.

Download the evidence and reproduce the scope

• Redacted log events and counter snapshots (text)
• Per-run timing table (CSV)
• Sanitized captures, environment, overrides and status samples (JSON)

The profile itself, its private key, complete certificate material and remote address are not included. Raw diagnostics remain outside the public web directory. Reproduction requires your own valid profile and an appropriate client. The commands below show the diagnostic shape; YOUR-PROFILE.ovpn is a placeholder, not a downloadable credential.

openvpn --config YOUR-PROFILE.ovpn --dev null \
+  --ifconfig-noexec --route-noexec --route-nopull \
+  --pull-filter ignore "dhcp-option" --script-security 1 \
+  --verb 4 --machine-readable-output --status PRIVATE-STATUS.txt 1 \
+  --connect-retry-max 1 --connect-timeout 10 --hand-window 15 \
+  --tls-exit --inactive 15 --remap-usr1 SIGTERM

The example uses shell-style line continuations for readability; use one line or the continuation syntax for your shell. The collector used argument arrays, a monotonic clock and a 40-second ceiling. Keep the original certificate and group requirements. These measurements add observed connection evidence to the verification guide; a throughput comparison still requires a separate controlled performance test.

Common questions

Did the test really negotiate SecP384r1MLKEM1024?

Yes. All three successful diagnostic connections explicitly reported that selected key-agreement group in their control-channel summaries. This result applies to these captures and this configuration.

Does the initialization time measure ML-KEM computation?

No. It includes client startup and protocol/network/readiness work. A configured route-delay path is visible in the logs. No pure cryptographic timing or comparative overhead was measured.

Why are there network bytes but no tunnel bytes?

OpenVPN exchanged control/protocol traffic with the server, while dev-null mode carried no application traffic through a TUN/TAP interface. Transport counters are not useful-payload throughput.

Why did the connection stop after about 15 seconds?

The diagnostic run explicitly set an inactivity exit. The logs show the expected soft inactivity termination and exit code 0, rather than a crash.