Thanks — I hear you: you’re seeing “ICE candidate: 701 Address not associated with the desired network interface” while testing a self-hosted LiveKit on an EKS private cluster, and the domain resolves to public IPs but the error persists. I’ll walk through the most likely causes and practical checks you can run. Key cause (short): LiveKit is likely advertising an internal/private IP (or a non-reachable address) in ICE candidates, so clients try to use that interface and fail. That can happen even when your domain resolves publicly if the server or TURN configuration still exposes private addresses. What you can check and try 1) Ensure LiveKit advertises the public domain/IP • Set the advertise address so ICE candidates use your public hostname: ◦ Example env vars in your deployment/Helm: ▪︎ LIVEKIT_ADVERTISE_ADDRESS = your-domain.com ▪︎ LIVEKIT_IP = your-public-ip • After changing, restart LiveKit pods and test again. 2) Verify TURN is configured and reachable • Make sure your TURN domain resolves to a public IP (turnlivekit.domain.com → public IP). • Confirm TURN listens on the expected ports and protocols: ◦ TLS/TCP on 443 if you use

turns:...:443?transport=tcp

◦ UDP/TCP on standard TURN ports if used • Confirm LiveKit is configured to use TURN: ◦ LK_TURN_ENABLED = true ◦ LK_TURN_URI includes your

turns:

URI ◦ LK_TURN_SECRET set correctly • To force testing through TURN on clients, set the WebRTC policy to relay: ◦ Example: connect options / rtcConfig:

iceTransportPolicy: 'relay'

◦ This helps confirm TURN relaying works independently of direct candidates. 3) Check network interface binding / what candidates are being generated • Inspect LiveKit pod logs for ICE candidate lines. You should see

typ srflx

(server reflexive) or

typ relay

(TURN) rather than only

typ host

(private host IP). ◦ Command: kubectl logs <livekit-pod> -n <namespace> • If you only see

host

candidates with private IPs, that indicates the advertise address isn’t applied or the container is binding to the internal interface. 4) Verify certificates and TLS • TURN over TLS requires valid certs. Self-signed certs often cause TLS/TURN failures. • Ensure

<http://turnlivekit.domain.com|turnlivekit.domain.com>

and your LiveKit domain both have valid CA-signed certificates (Let’s Encrypt or other CA). 5) Firewall / routing checks • Ensure firewall / security groups allow required inbound/outbound: ◦ TCP 443 (if using TLS TURN) ◦ UDP 3478/5349 and any other ports your TURN uses • From an external machine, test connectivity to the TURN host/port (e.g., curl or openssl s_client for TLS). 6) Use the LiveKit Connection Tester • Run the LiveKit connection test utility to check WebRTC, WebSocket, and TURN connectivity. It helps isolate whether the issue is ICE, DTLS, or TURN-related. If you want, I can help more precisely — please provide: • The LiveKit pod logs showing ICE candidate output (redact secrets). • Your LiveKit env vars related to advertise address and TURN (LIVEKIT_ADVERTISE_ADDRESS / LIVEKIT_IP / LK_TURN_*). • The exact TURN URI you’re using (anonymize secrets), and whether the TURN server uses a CA-signed cert. • Whether clients are on the public internet or behind a corporate/NAT/proxy. If you share those, I’ll point to the next targeted steps (what to change and what to watch in logs). Sources: Firewall Tips for LiveKit Connectivity | LiveKit | Configure ZScaler proxy for LiveKit connections | LiveKit | Diagnosing Connection Errors with Connection Test Utility | Diagnosing Connection Errors with the Connection Test Utility | LiveKit