The existing coturn instance advertises the router's public IP as its
relay address (external-ip=94.255.139.35) — correct for real external
users, but when both peers are on the same home network as the router,
relay traffic has to hairpin through the router's own WAN IP. That only
worked with hwnat (hardware NAT offload) disabled, which pegged the
router's CPU at 93% for well under half its rated throughput — not an
acceptable trade for the whole household's network.
Instead of touching hwnat, added a second coturn deployment
(coturn-lan, own secret, own relay port range 49210-49220) exposed via
its own MetalLB LoadBalancer IP (10.10.3.46) on the same LAN segment.
That address is answered directly via L2 ARP — no NAT, no hairpin,
hwnat never touches it — and it's deliberately not port-forwarded from
WAN, so it's LAN-only by construction.
iceConfig() now appends this as an extra iceServers entry whenever
TURN_LAN_HOST/TURN_LAN_SECRET are set. It's harmless for anyone not on
that network — the address is simply unreachable and ICE ignores it —
and WebRTC tries every configured server, using whichever candidates
actually connect.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"restarting ICE" on a connection that has reached 'failed' only restarts
ICE gathering — it reuses the same DTLS transport and certificate. If
that transport is what's actually broken, the next renegotiation throws
"Failed to set SSL role for the transport" (DTLS role can't be flipped
on an established transport), which is exactly what showed up in the
console on a LAN test, ruling out NAT/TURN as the cause.
Fix: on 'failed', fully close and recreate the RTCPeerConnection (fresh
certificate, nothing to conflict with) via recreatePeerConnection().
Since ICE/DTLS failure isn't guaranteed to fire on both ends at once,
the side that notices sends a new 'reset' signal (relayed by the
server like offer/answer/candidate) telling the other side to tear
down and wait for a fresh offer too — otherwise its old, now-mismatched
transport would just fail the same way against our new one. Capped at
3 rebuild attempts per peer before giving up with a toast, reset on any
successful 'connected' state.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Node's default keepAliveTimeout (5s) is shorter than ingress-nginx's
default upstream keepalive idle timeout (60s). Under that mismatch,
nginx can forward a request onto a pooled connection Node has *just*
closed, which the browser sees as a 502 — and it never shows up in
this process's own traces because Node never received the request.
/api/rooms is polled every 5s from idle clients, landing almost
exactly on that 5s boundary, which is why it was the one showing up
for external users.
Also add abort/slow-request logging (tagged with the active trace ID
so it can be pivoted to from RUM) and a clientError handler, so a
genuine backend-side failure is now visible instead of indistinguishable
from the proxy-side race.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mats
