Firewall requirements on Kubernetes

Diagram for port configuration, and list of active ports, for an IBM® API Connect deployment on Kubernetes.

Required Ports between zones

The following network diagram example helps to explain which ports must be configured in an API Connect network. Specific ports must be configured to enable the communication between the various zones, both public and private, in a network.

The ports specified in the diagram are default ports. Check your deployment to understand which communication, if any, is configured to use non-default ports.

Network diagram
Table 1. Key for the network diagram example.

The following table lists the port numbers with a usage description.

  Usage description Default port number
 1  API request/response – Users invoking the provided APIs. 443 HTTPS from Public zone to Gateway zone
 2  DataPower® administration – Internal operators who are managing the Gateway servers. 22 SSH, 9090 HTTPS from Protected zone to Gateway zone
 3  API Manager – Internal business users who are defining and monitoring APIs. 443 HTTPS from Protected zone to Management zone
 4  Cloud Manager – Internal operators who are administering the Cloud. 22 SSH, 443 HTTPS from Protected zone to Management zone
 5  Developer Portal administration – Internal operators who are managing the Portal servers. 22 SSH, 443 HTTPS from Protected zone to Management zone
 6  Gateway servers post traffic to Analytics service. 443 HTTPS from Gateway servers to Analytics service
 7  Push configuration – Management servers communicate bi-directionally with Gateway servers. 3000 and 443 HTTPS Management servers to and from Gateway servers for webhook delivery. Port 3000 is the default port for apic-gw-service, and this is the port Management uses to communicate with Gateway. Port 443 is the default port for the platform-api endpoint, which apic-gw-service uses to communicate with Management.
 8  Push configuration/webhooks – Management servers push configuration and webhooks to the Developer Portal. 443 HTTPS Management servers to Developer Portal servers for webhook delivery
 9  Pull configuration/make API calls – Developer Portal servers pull configuration and call REST APIs. 443 HTTPS from Developer Portal servers to Management servers within Management zone
 10  Developer Portal – External developers who are accessing the Developer Portal. 443 HTTPS from Public zone to Developer Portal management zone. The reverse proxy/DataPower WAF for incoming web traffic to the Developer Portal cluster must be a transparent proxy - no modification of the portal URL, port, host name or path is allowed.
 11  Push API definition to Management server. Pick up credential for microservice code push. 443 HTTPS from Protected zone to Management zone
 12  Analytics offload Port will depend on type of plugin and protocol used for the offload. Some possible protocols are: HTTP, HTTPS, TCP, UDP, KAFKA
 13  Analytics accesses NTP Standard NTP
 14  Analytics access DNS Standard DNS
 15  Management service queries Analytics service 443 HTTPS within Management zone
 16  The Portal service invokes an API (GET) on the Analytics service to retrieve data. 443 HTTPS within Management zone
 17  External billing service – Management cluster connecting to external billing service (when configured for billing). If you are using Stripe as your external billing service, you must enable connections with the Stripe API at: You can also view the Stripe IP addresses at the following URL: 443 HTTPS from Management zone to Public zone
 18  Developer Portal cluster must be able to access its own site endpoints. 443 HTTPS from Portal zone to Public zone

Firewall port requirements on Kubernetes

The following tables lists ports that must be open in both cluster and non-clustered deployments.

Table 2. Firewall port requirements common to all subsystems
Subsystem Ports and description
Ports that must be open on all API Connect subsystems

The following ports must be open on the Management Server, Analytics, and Developer Portal subsystems, whether in a cluster or not.

  • 22 (outbound) Used for SFTP backups on Management and Portal subsystems
  • 53 (outbound) DNS
  • 123 (outbound) NTP
  • 443 (inbound and outbound) Used by all subsystems for communication with other subsystems
  • 44135 (inbound and outbound)

Each subsystem uses ports in addition to the ports in Table 2. See the following table.

Table 3. Additional firewall port requirements for each subsystem
Subsystem Ports and description
Management Service

Management Service uses the ports in Table 2 plus:

  • 22 remote backup server port (configurable)

    If backups are configured to use another port, ensure that the port is open.

  • 161 (inbound) SNMP
  • LDAP server port (if using LDAP user registry), typically 389 (outbound)
  • 3007 (outbound) LDAP

The Automated test behavior application must be able to invoke (outbound) any port that a test system might present an API on. It can be bound to a particular port (if it is the same in all environments) or to a range of ports (to cover all of the ports it might invoke).

Developer Portal

The Developer Portal uses the ports listed in Table 2, plus:


The Analytics subsystem uses the ports listed in Table 2.

Analytics port usage considerations:

  • 161 for SNMP is required for both non-clustered and clustered deployments
  • In a non-clustered deployment, no additional ports are required.
  • Analytics supports an optional configuration for offload of data. This configuration might require additional outbound ports to be open.
Gateway Server The Gateway Server uses these ports in both non-clustered and clustered deployments:
  • 161 (inbound and outbound) SNMP
  • 162 (outbound) SNMP traps
  • 3000 (inbound) Gateway Service local port (configurable)
  • 5550 (inbound) XML management port (configurable)
  • 5554 (inbound) REST management port (if enabled; configurable)
  • 9022 (inbound) Gateway SSH (if enabled; configurable)
  • 9090 (inbound) Web GUI console (if enabled; configurable)
  • 9443 (inbound) Gateway local port (configurable)

Communications inside the Gateway cluster

There are a number of important points to note regarding the communications within the Gateway cluster.

  • We advise that you use the same port for all Gateway servers within a cluster.
  • Gateway servers communicate with each other to synchronize invocation counts.
  • All Gateway servers in a Gateway cluster must be able to reach all of the other Gateway servers in the same Gateway cluster.
  • Gateway servers in a Gateway cluster do not directly communicate with Gateway servers in a different Gateway cluster.
  • All Gateway servers must be able to reach the management subsystem platform API endpoint, which was configured during the installation of your API Connect environment.

Ethernet interface usage

To separate network traffic, you can use two or more Ethernet interfaces on the DataPower appliance on which a Gateway server is installed. For example, you can use one interface for internal IBM API Connect communications, and another for processing incoming API calls.

Port requirement for Stripe billing service

All Management servers and Developer Portal servers must be able to communicate HTTPS content with the external billing service when billing is configured. If you are using Stripe as your external billing service, you must enable HTTPS communication on port 443 with the Stripe API:
Note: API Connect does not support using webhooks with Stripe. You can see a list of the Stripe IP addresses at: