Firewall requirements
Diagram for port configuration, and list of active ports, for an IBM® API Connect deployment on Kubernetes or OpenShift.
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.
| 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 | 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: https://stripe.com/files/ips/ips_api.json. You can also view the Stripe IP addresses at the following URL: https://stripe.com/docs/ips. | 443 HTTPS from Management zone to Public zone |
| 17 | Developer Portal cluster must be able to access its own site endpoints. | 443 HTTPS from Portal zone to Public zone |
Firewall port requirements
The following tables lists ports that must be open in both cluster and non-clustered deployments.
| 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.
|
Each subsystem uses ports in addition to the ports in Table 2. See the following table.
| Subsystem | Ports and description |
|---|---|
| Management Service |
Management Service uses the ports in Table 2 plus:
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:
|
| Analytics |
The Analytics subsystem uses the ports listed in Table 2. Analytics port usage considerations:
|
| Gateway Server | The Gateway Server uses these ports in both non-clustered and clustered deployments:
|
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.