cloudflare / cloudflare/boringtun

0.7.1 regression: sessions go one-way deaf ~15-30s after handshake (0.6.0 stable)

Open
#495 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
7.2k
Forks
532
PR merge metrics
No merged PRs in 30d

Description

## Summary
With 0.7.1 (`Tunn` as a library, no tun device), established sessions go **one-way deaf ~15–30 s after each handshake**: the peer (ProtonVPN server) stops sending transport packets entirely, while handshake initiations still get responses within ~30 ms. Traffic recovers only when the `KEEPALIVE + REKEY_TIMEOUT` timer fires a new handshake ~15 s later. Result: ~15 % of client requests time out, cycle repeats every ~30 s.

Pinning `boringtun = "0.6.0"` with otherwise identical code fixes it completely.

## Environment
- boringtun 0.7.1 vs 0.6.0, `default-features = false`, `Tunn` API only (onetun-style: smoltcp virtual stack, single UDP socket, `update_timers` every 250 ms)
- macOS 15 (arm64), server: ProtonVPN (multiple servers, same result), keepalive 25 s

## Evidence
- 40 TCP fetches through the tunnel, one every 3 s: **0.7.1 → 34/40 ok, 0.6.0 → 40/40 ok**; onetun 0.3.10 (boringtun 0.6) on the same server/network → 40/40.
- During a deaf window: zero datagrams arrive on the UDP socket (kernel Recv-Q stays 0, no decapsulate errors), yet a handshake initiation sent mid-window is answered in ~30 ms → path and server fine, session state is not.
- `WARN HANDSHAKE(KEEPALIVE + REKEY_TIMEOUT)` every ~30 s in logs; each new session repeats the pattern.
- Ruled out: endpoint roaming (server source never changes), local socket buffer drops, DNS (raw TCP-by-IP shows it too).

## Repro sketch
Drive `Tunn` directly against a WireGuard server (ProtonVPN reproduces reliably): handshake, send steady TCP traffic through it, watch inbound stop ~15–30 s after session establishment while handshakes keep working.

Happy to run diagnostics/bisect builds if useful.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the regression through the Tunn API with a WireGuard server and inspect timer handling around update_timers, handshakes, and decapsulation. Compare 0.7.1 with 0.6.0 while tracing the KEEPALIVE + REKEY_TIMEOUT cycle; done means sustained inbound transport traffic without deaf windows and a regression test covering the failure.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.