AI Gateway Connectivity Reference

Every hostname, port, and direction a hybrid data plane needs, and the inspection and filtering decisions that break it

This page exists to answer one question completely: what does a network team have to open so that a self-hosted AI Gateway data plane can reach Strata Cloud Manager and the models it proxies for. It applies to every hybrid platform, since the data plane makes the same calls whether it runs on EKS, AKS, GKE, ECS, Azure Container Apps, or an on-premises cluster.

The deployment guides cover connectivity in the context of their own procedures. This page is the consolidated list, written to be handed to whoever owns the firewall.

The Strata Cloud Manager URL is not what you open

Prisma AIRS AI Gateway is built on Portkey, which Palo Alto Networks acquired and integrated behind Strata Cloud Manager. The console you administer is SCM. The endpoints the data plane calls are still the Portkey management plane hostnames, under portkey.ai. Both facts are true at once, and seeing portkey.ai in your firewall logs is expected rather than a sign of misconfiguration.

Two consequences follow. A network team given only "allow Strata Cloud Manager" will open the wrong thing. And a security review that sees traffic to a domain nobody recognizes may block it, which produces the failure described under TLS Inspection.

Direction of travel

All connectivity is outbound only, over TCP 443. The data plane initiates every connection. Responses return on connections it opened, which is not the same as an inbound connection and does not need a firewall rule of its own.

What to open from the pods

These are the destinations the gateway process itself calls. On Kubernetes they are what a pod-level egress policy governs; on ECS or Container Apps they are what the task or replica needs.

Read the authoritative list off your own gateway

kubectl exec -n airs-gw <GATEWAY_POD> -- env \
  | grep -E 'BASEPATH|CONFIG_READER_PATH' | sort

That returns the base paths the data plane actually uses, which is what belongs on the firewall request. Confirm the result with your account team before a production change, and treat the table above as a starting position rather than the final word.

To see which of them carry traffic in practice, enable query logging on CoreDNS and read the log after the gateway has run for a few minutes. Exclude any shell testing you do yourself: a wget from inside the pod goes through CoreDNS and is indistinguishable from gateway traffic.

What to open from the nodes

Cloud service endpoints

These are specific to where the data plane runs and to the storage and identity choices you made. They are easy to forget because they are not part of the product's own endpoint list.

Filter by hostname, not by address

None of the management plane endpoints publish stable addresses, and the published figures that do circulate relate to an inbound path that Strata Cloud Manager does not support. Build the allow-list on hostnames.

This has a direct consequence for Kubernetes. A NetworkPolicy matches on IP ranges and cannot express a wildcard hostname, so it cannot implement *.portkey.ai. Hostname filtering belongs on a firewall in the egress path. Use NetworkPolicy to constrain which pods may egress at all, and the firewall to constrain where they may go.

Kubernetes permits all egress by default. Where a cluster applies restrictive policies, the gateway needs an explicit allowance or it will never register. The published example below is deliberately permissive so a first deployment works; narrow the CIDR once the deployment is proven.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-gateway-egress
  namespace: airs-gw
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0

TLS inspection

Add a decryption exemption for *.portkey.ai and for every LLM provider endpoint you integrate. The gateway validates the certificate chain it expects, so a re-signed certificate fails the handshake.

This deserves more attention than a single line in a prerequisites list, because inspection breaks the deployment in three independent places, the symptoms look nothing alike, and fixing one leaves the others broken.

echo | openssl s_client -connect api.portkey.ai:443 \
  -servername api.portkey.ai 2>/dev/null \
  | openssl x509 -noout -issuer

Your source address

Where an intermediate firewall needs to allow traffic by source, the address presented depends on how the compute egresses, and the answer is often not what the architecture diagram implies.

• Private subnets behind NAT — the source is the NAT gateway's Elastic IP or equivalent. With one NAT gateway per Availability Zone there is more than one, so supply all of them.
• Public subnets with auto-assigned addresses — the source is each node's own public address, which changes whenever a node is replaced. Source-based allow-listing is impractical in this shape.

Confirm which applies before committing to a source range, because the cluster creation command does not always place nodes where people assume:

kubectl exec -n airs-gw <GATEWAY_POD> -- wget -qO- https://checkip.amazonaws.com

Verification

Work outward. Each check isolates a different layer, and running them in order stops you diagnosing a firewall problem that is really a credential problem.

kubectl get pods -n airs-gw
kubectl describe pod -n airs-gw <POD> | sed -n '/Events:/,$p'

kubectl exec -n airs-gw <POD> -- \
  wget -q -O /dev/null https://api.portkey.ai/ \
  && echo reachable || echo blocked

kubectl exec -n airs-gw <POD> -- node -e '
require("https").get("https://api.portkey.ai/",
  r => console.log("OK", r.statusCode))
  .on("error", e => console.log("ERR", e.code))'

kubectl port-forward -n airs-gw <GATEWAY_POD> 8787:8787

curl -X POST "http://localhost:8787/v1/messages" \
  -H "Authorization: Bearer <GATEWAY_API_KEY>" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "@<slug>/<model>", "max_tokens": 32,
       "messages": [{"role": "user", "content": "Say OK"}]}'

Symptom lookup

Sourcing and confidence

Connectivity guidance is worth stating with its provenance, because a firewall change request is hard to retract and the published sources disagree with each other.

Related guides

• AI Gateway Deployment — licensing, gateway registration, integrations, and guardrails.
• Hybrid Infrastructure — architecture, sizing, and per-platform prerequisites.
• EKS, AKS, and GKE — the Helm deployment procedure.
• ECS and Container Apps — the Terraform deployment procedure.