# 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

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