Hi everyone,
We’re currently running an agent on LiveKit Cloud and need some help regarding IP whitelisting.
Our backend APIs are protected by a WAF, and the agent needs to call these APIs. To allow this, we tried whitelisting the EU region static IPs listed in the LiveKit documentation:
https://docs.livekit.io/deploy/admin/firewall/#static-ips
However, even after whitelisting those IPs, our requests from the agent are still getting blocked by the WAF.
Could someone clarify the following?
-
Are the IPs listed in the documentation the only outbound IPs used by agents in the EU region?
-
Is there a possibility that additional dynamic IPs are used when agents make outbound API calls?
-
If agents run in LiveKit Cloud, what is the correct IP range or method we should whitelist to allow our APIs to be accessed reliably?
Any guidance would be greatly appreciated. Thanks in advance!
Sorry, we do not currently have a fixed CIDR range for LiveKit-hosted agents.
Oh! How do you best propose we solve for this? Because, the rooms are not getting triggered.
Not sure I understand what you mean by that. Agents should be joining rooms.
I am not sure how you should handle your servers API access layer. Many use a token access in the authorization header. Currently an agent request can come from dynamic IP ranges.
We are working on moving that to a known CIDR range but it is not currently available.
Presumably you are aware of this, since you explicitly state LiveKit Cloud in your question, but another option would be to self-host your agents, outside of LiveKit cloud: Self-hosted deployments | LiveKit Documentation . You could still leverage LiveKit cloud’s infrastructure for WebRTC, and to manage your agents, but self-hosting agents would give you full control over their hosting infrastructure.
Nice — so LK agents can run seamlessly in both Cloud and self-hosted environments.
The LK agents are WebSocket clients, so no need to worry about CIDR. Amazing.
LK Agents use a WebSocket for signaling, and connections to the various inference services. Client communication (SIP or WebClient) is via WebRTC.
Worth re-anchoring on the original question: @futadanewson’s “WebSocket = no CIDR worry” conflated layers, and @CWilson’s correction covers signaling/inference but not what @Shivam_Gupta asked about (the agent’s outbound call to a WAF-protected backend).
- The doc OP linked is the wrong direction.
/deploy/admin/firewall/#static-ipsis for whitelisting LiveKit Cloud endpoints on the customer’s network, not the agent’s outbound source IPs hitting your backend. That’s why those IPs didn’t help.
- I would second @CWilson’s answer as it still holds. No published
CIDR for Cloud Agents outbound exists in the current firewall doc (re-checked just now).
- Workarounds in practice: auth at the application layer (signed JWT / shared-secret header), @CWilson’s path; self-host the worker (@darryncampbell’s path) for full egress control; or route the agent’s HTTP client through a forward proxy on a static IP you own (
Squid / nginx / Cloudflare), which keeps you on Cloud Agents and gives the WAF a single IP to whitelist.
I received an email from the LiveKit team regarding changes to their static IP ranges.
The change applies not only to SIP and webhooks, but also to outbound calls from LiveKit Agents and real-time media traffic.
Does this mean the IP whitelisting issue can now be resolved by adding LiveKit’s new static IP range?
@Takashi_Futada good catch, and I am going to follow up internally.
The point in the email about “outbound calls from LiveKit Agents to allowlisted external services” will only affect a small number of enterprise customers. A range is static IPs for hosted agents is not generally available.