Network Ports and Firewall
This page defines the common network surfaces used by Wavry.
Port Overview
| Component | Protocol | Default | Purpose |
|---|---|---|---|
| gateway | TCP | auto-allocated host port (3000 in-container) | auth/signaling/control APIs |
| relay | UDP | auto-allocated host port (4000 in-container) | encrypted relay forwarding path |
host runtime (wavry-server) | UDP | dynamic/configured | encrypted media + input transport |
Recommended Firewall Baseline
- Allow inbound TCP to gateway from trusted client ranges.
- Allow inbound UDP to relay only if relay fallback is enabled.
- Restrict admin/control paths to trusted networks.
- Keep least-privilege egress policies for runtime nodes.
NAT and Connectivity Notes
Wavry is direct-path first.
If direct connectivity fails, session may fall back to relay.
High relay usage usually indicates:
- restrictive NAT/firewall policy
- invalid candidate addresses
- asymmetric routing constraints
Validation Commands
Gateway health (discover mapped port first):
docker compose -f docker/control-plane.compose.yml port gateway 3000
Control-plane state:
docker compose -f docker/control-plane.compose.yml ps
Basic UDP listener check (relay host):
docker compose -f docker/control-plane.compose.yml port relay 4000/udp
Production Recommendations
- Put gateway behind TLS termination and ingress controls.
- Use region-aware relay placement for latency-sensitive users.
- Monitor direct/relay ratio continuously.
- Alert on sudden relay ratio shifts after network changes.
Incident Triage for Network Faults
- confirm control-plane health
- identify direct vs relay session path
- verify firewall/NAT changes in incident window
- rollback recent network policy changes if correlation is strong