VPN baseline 0.2.87

Date: 2026-05-05

This document freezes the current near-working VPN state. Treat it as the rollback and comparison point before changing the Android VPN dataplane, gateway assignment, mesh route intents, or packet relay behavior.

Baseline components

Android client: 0.2.87 / version code 87
APK path: web-admin/deploy/html/downloads/rap-android-rdp-vpn-latest-release.apk
Known-good APK path: web-admin/deploy/html/downloads/rap-android-rdp-vpn-known-good-0.2.87.apk
Versioned APK path: web-admin/deploy/html/downloads/releases/0.2.87/rap-android-rdp-vpn-0.2.87-release.apk
APK sha256: bc44304658df7cd0ad627660c9e7b37af68910cdb13b310314ab99a049ff3b8d
APK size: 1187103
Backend image: rap-backend:vpn-dataplane-contract-0.2.86
Node/host agents: 0.2.86
Cluster: cfc0743d-d960-49fb-9de8-96e063d5e4aa
VPN connection: 7cc94b0d-9cc2-4492-956a-cb0913b887e2 (home-full-tunnel)
Entry node: home-1 (8ad04829-cd30-4290-913d-1ce5c7ef7bb3)
Exit node: home-1 (8ad04829-cd30-4290-913d-1ce5c7ef7bb3)
DNS from exit side: 192.168.200.210
Client tunnel: full tunnel, 0.0.0.0/0, VPN address 10.77.0.2/24
Active gateway lease: home-1, generation 8
Active relay transport: backend_http_packet_relay

Current working behavior

General web traffic passes through the VPN.
External sites open through the configured home exit.
Telegram can connect, but initial connection may be delayed.
RDP can connect through the tunnel, but long-lived sessions can still drop.
Speed is the best observed so far, but speed-test pages may delay loading their plugin/script parts.

Observed diagnostics

Latest phone diagnostics for device 37574bd4-b944-440f-bbd5-87f2980d22c4 reported Android app version 0.2.87.

Packet relay counters showed both directions are active:

client_to_gateway: no queue drops observed, queue depth returned to 0
gateway_to_client: queue depth was observed at 48-55
gateway_to_client: 246 dropped packets were observed
Android side recorded downlink traffic, uplink traffic, and several uplink sender errors
Android source validation dropped packets whose source was not the VPN address; keep this guard enabled

Interpretation: the active path is real and carries traffic, but downlink backpressure or Android TUN drain stalls can still interrupt long-lived TCP flows. This explains delayed Telegram startup, speed-test plugin loading delays, and RDP sessions that connect and later drop.

Guardrails

Do not reduce Android TUN_WRITE_MAX_RETRIES below 1000 without a controlled regression test.
Do not relax Android VPN source-address validation.
Do not re-enable the home-1 vpn_packets fabric mesh route intent for this connection until the Android client can intentionally use the fabric entry path. The current working baseline relies on backend_http_packet_relay.
Do not change the active entry/exit away from home-1 without saving packet counters before and after.
Do not change DNS away from 192.168.200.210 without checking full-tunnel DNS and direct-IP traffic separately.
Keep the 0.2.87 APK available as a known-good rollback artifact.

Next safe work

Stabilize gateway_to_client downlink queue draining and Android TUN write backpressure.
Add clearer per-flow counters for long-lived TCP flows such as RDP.
Add a small repeatable smoke test: DNS, direct IP HTTP, 2ip.ru, Telegram-like long connection, and RDP port reachability.
Only after this baseline is stable, move Android entry traffic from backend relay to fabric mesh.

3.6 KiB Raw Blame History