We’re running an agent on LiveKit Cloud that needs to call APIs on our servers (protected by a WAF). For this, we tried whitelisting the EU region static IPs listed in the LiveKit docs: https://docs.livekit.io/deploy/admin/firewall/#static-ips However, the requests are still getting blocked by the WAF. Could you confirm which IP addresses or ranges should be whitelisted for outbound requests from agents running on LiveKit Cloud (EU region)?

Thanks for reaching out, Rohit. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Source IP shown in the logs is - 130.61.233.251. It is deployed to EU region

Thanks — I see the source IP in your WAF logs is 130.61.233.251 and the agent is deployed to the EU region. I’ll explain what that means and give clear next steps to get your requests unblocked. What this means • The documented LiveKit Cloud static egress CIDRs to whitelist are: ◦ 143.223.88.0/21 ◦ 161.115.160.0/19 • The source IP you reported, 130.61.233.251, is NOT in those ranges. This can happen because LiveKit Cloud does not guarantee that every outbound request from every service or agent will originate from the static IP blocks, even when region-pinned. • In short: relying only on those two CIDR ranges can fail for agent-initiated outbound API calls. Practical next steps to unblock traffic 1. Temporarily allow the observed IP ◦ Add 130.61.233.251 to your WAF allowlist for testing so your agent’s calls succeed right away. ◦ After confirming functionality, remove the single-IP exception if you prefer a more robust approach below. 1. Move to a more reliable allowlisting method ◦ If possible, allow by hostname/domain (your backend endpoint) rather than by source IP. This avoids problems with dynamic egress IPs. ◦ If your WAF supports CIDR ranges plus occasional dynamic egress, keep the two LiveKit CIDRs (143.223.88.0/21 and 161.115.160.0/19) and add short-lived exceptions for additional IPs you observe. 1. Collect evidence for recurring blocks ◦ When you see a blocked request, capture: ▪︎ The source IP (you already have 130.61.233.251) ▪︎ Timestamp (UTC) ▪︎ Example request path or agent ID (redact any sensitive payload) ◦ Share one or two of these samples and I’ll help interpret patterns and suggest the best allowlist strategy. 1. Verify deployment settings ◦ Double-check the agent’s configured region in your deployment to confirm it’s set to the EU region (you noted it is, but confirming prevents mis-pinning). ◦ Make sure there is no intermediate proxy/NAT that could change the visible source IP. If you want, I can: • Help interpret additional WAF log entries (redact sensitive data). • Suggest a short-term WAF rule you can apply safely for testing. • Walk through steps to allowlist by hostname or to create a fallback rule that only opens for specific agent endpoints. Tell me which option you prefer (temporary IP allowlist, hostname-based allowlist, or gather more log samples) and share one blocked-request timestamp and any other blocked source IPs you see. I’ll guide you through the precise next change. Sources: Checklist for Regional Deployments | LiveKit | Support data sovereignty in India | LiveKit

If possible, allow by hostname/domain (your backend endpoint) rather than by source IP. This avoids problems with dynamic egress IPs. How can I do this? How to know domain and hostname?

Thanks — I’ll walk you through how to allow by hostname/domain and how to identify the correct hostnames to allow for your setup. A couple of important points up front • You want to allow your backend’s domain (the server your agent calls), not LiveKit’s. Hostname-based allowlisting means letting requests from anywhere reach your backend only when the request targets your backend’s hostname. • LiveKit agents may egress from dynamic IPs, so allowing by domain at your WAF is the more reliable approach than relying solely on LiveKit static CIDRs. How to allow by hostname/domain (high-level steps) 1. Determine the backend hostname(s) your agent calls ◦ Look at the agent configuration or code to find the base URL it uses for API calls (examples:

<https://api.example.com>

, `https://internal.example.org:8443`). ◦ If you don’t have code access, inspect the WAF logs for the blocked requests’ Host header or the request URL path — the Host header shows the hostname the agent targeted. 1. Create a WAF rule that allows requests targeting that hostname ◦ Configure the WAF to allow inbound requests where the Host header equals your backend domain (exact match or wildcard as appropriate). ◦ If your WAF supports SNI inspection, allow by SNI hostname for TLS (this matches the TLS handshake hostname). ◦ If your WAF ruleset requires an IP target, combine hostname-based allowlisting with DNS resolution (see considerations below). 1. Restrict who can reach that hostname ◦ Scope the rule so it only applies to the specific API paths the agent calls (e.g.,

/api/agents/*

) and specific HTTP methods if possible. ◦ Require strong authentication (mutual TLS, bearer token, signed requests) so allowing the hostname does not open the endpoint to abuse. 1. Test and monitor ◦ Temporarily enable the hostname rule and repeat the API calls from the agent. ◦ Confirm in WAF logs that the traffic is now allowed and that the Host/SNI matches your rule. How to identify the exact hostname if you’re unsure • Check your agent’s configuration or environment variables for API_BASE, BACKEND_URL, or similar keys. • Inspect recent blocked request entries in the WAF log: ◦ Look for the Host header or the full request URL shown in the log entry. ◦ For TLS connections, check the SNI value captured by the WAF (if available) — SNI is the hostname presented during TLS handshake. • If you can capture a sample request (timestamp, redacted path), share the Host header or SNI and I’ll confirm the exact string to allow. Practical considerations and common pitfalls • DNS and load balancers: If your backend uses a load balancer or CDN, allow the public hostname (the one clients call). Don’t try to allow an internal IP unless you control the egress and source IPs. • Wildcards: Use wildcards carefully. Allow

<http://api.example.com|api.example.com>

rather than

*.<http://example.com|example.com>

unless you need broader coverage. • TLS termination: If TLS is terminated at a CDN or LB, SNI/Host will reflect the public hostname — use that value. • Authentication: Hostname allowlisting is an access-layer control — keep authentication/authorization enforced on your API so someone else can’t call it just because the hostname is reachable. • If your WAF only supports IP-based rules: You can combine hostname checks with resolved IPs — resolve the hostname to the current IPs and allow those, but this reintroduces dynamic-IP issues and needs monitoring for DNS changes. If you’d like, I can: • Confirm the exact hostname to allow if you share the Host header or SNI from a blocked request (redact any sensitive path or credentials). • Suggest a minimal WAF rule example tailored to your WAF vendor if you tell me which WAF product you’re using. Which would you like to do next — share a sample Host/SNI from a blocked log entry, or tell me your WAF vendor so I can suggest a concrete rule?

Do you mean we would allow all IPs to call the particular API? If not, can you explain in easy words?

Great question — and you’re right to be careful. Short answer: allowing by hostname does not have to mean “allow everyone” — you can (and should) combine hostname-based rules with other checks so only your LiveKit agents can call your API. Simple explanation • Hostname-based allowlisting means your WAF looks at the requested hostname (the Host header or TLS SNI) and allows requests that target that specific domain — for example, api.example.com. • That alone only ensures the request was addressed to your API hostname. It does NOT prove the caller is trustworthy, because anyone on the internet can send a request with that Host header. How to make hostname allowlisting safe (easy steps) 1. Allow requests to your API hostname (example: api.example.com) ◦ This lets traffic that targets your API reach your servers even if the source IP is dynamic. 1. Require strong authentication so only authorized callers succeed ◦ Use one or more of: ▪︎ API keys or bearer tokens checked by your server ▪︎ OAuth tokens ▪︎ Mutual TLS (mTLS) so callers must present a trusted client certificate ▪︎ Signed requests (HMAC) so you verify the request came from a holder of a secret ◦ Only authenticated requests should be accepted by your application. 1. Scope the WAF rule tightly ◦ Limit allowed requests to specific paths and methods the agent uses (for example, allow POST /agent/callback but not the entire site). ◦ Add rate limits and anomaly detection to reduce abuse. 1. Add extra checks if possible ◦ If your agents include a custom header or a unique client ID, have the WAF or your app validate it. ◦ Require TLS and inspect SNI to ensure clients are connecting to the correct hostname. ◦ Log and monitor blocked/allowed attempts and alert on unusual activity. Example—putting it together • WAF rule: Allow inbound TLS where SNI = api.example.com and request path starts with /agents/. • Server-side: Require mTLS or a bearer token for any request under /agents/. • Result: Any IP can reach the hostname, but only callers with valid certificates or tokens can actually use the API. When hostname allowlisting might not be enough • If you need to guarantee only LiveKit egress IPs can reach your API, hostname rules aren’t sufficient by themselves because they don’t restrict source IPs. In that case you can: ◦ Combine hostname allowlisting with temporary IP exceptions for observed LiveKit IPs, or ◦ Use mTLS or per-agent credentials so you don’t need to trust IPs. If you want, I can: • Look at a sample blocked log entry’s Host/SNI and give the exact hostname to allow. • Draft a minimal WAF rule example tailored to your WAF vendor (tell me which WAF you use). • Recommend an authentication approach (mTLS, token, or signed requests) based on how your agents are built. Which would help most — a WAF rule example for your vendor, or a recommendation on which authentication method to add?