When you deploy any of the WSO2 products on your local machine you really do not have to think about enabling ports for communication (WSO2 ports of call). However, when you move to more of a real world setup this changes.
The reason, of course, is that servers that are connected to the internet or even internal networks often have restrictions as to the traffic and ports. In other words, you might be able to install the software but with port restrictions the software does not work.Let’s say that we have a setup like this:
- Distributed API manager
- Clustered Enterprise Service Bus
Although this looks like a simple setup it is however quite a setup as you can see from this image:
Each of the boxes is a different server. We also indicate that all API invocations go to the load balancer fronting the ESB. This choice is arbitrary of course and can be substituted by any other setup. Some alternatives could be:
- Using WSO2 IS or other IAM solution rather than the key manager included in the API Manager
- Combining more than one component on a server, e.g. publisher and store
- Clustering any component for HA and load balancing
- The ESB could have a manager node that will make sure updates are pushed to the worker nodes
Setting up a zone
In order to make this more of a tutorial I’ve decided to use centos and the firewall application to mimick every step.
Let’s start by identifying what elements we have here:
- API Manager (distributed) with a manager node
- ESB (stateless and fronted by a load-balancer)
- MariaDB as the database
Let’s assume that all products run on a separate server, in other words we can actually use a zero offset for all products. When more than one product runs on a server a port offset is needed otherwise WSO2 will throw an error since ports are already in use. Just to remind: an offset will move the port number in use with the amount of the offset, so the 9943 admin port with an offset of 1 will become 9444.
So for all of the servers, let say that the range is xxx.xxx.xxx.001 to xxx.xxx.xxx.009 we need to open the incoming port on 9443 (https) and 8243(http). This will allow a browser to gain access to the management console. The MariaDB server does not need that, we assume that we access the database using a terminal session, we only need to open up the port for the default database traffic which is on port 3306.
Specific ports
For the ESB we need to open traffic to the ports on which the proxies, apis and other artifacts are running. That means for a default setting: 8280 for http based artifacts and xxxx for https based artifacts.
If you have defined any inbound endpoints, like for instance an http listening endpoint (e.g. 8285) you need to include them as well. The same goes for any transports that you use (defined in the axis2.xml).
For the API manager we need to open the ports on which the api’s are running, so again the xxxx http and xxxx https ports.
So now we have the external stuff covered. With external we mean the communication to the management UI and jiggery apps like portal and store.
Analytics
In this setup we also have two analytics solutions (ESB and API) that are actually WSO2 Data Analytics servers and the API Traffic Manager which is a WSO2 Complex Event Processer (CEP).
The Analytics servers gather information from the gateway or the ESB and aggregate, analyse and display it. The protocol in use is the thrift (TCP) protocol both the unsecure and secure version of it. So we need to open the ports to allow this as well. For a default offset on these products (which is 1 as to not interfere with the accompanying ESB or API Manager)., the ports are 7612 and 7712. So these need to be opened as well. However, since we set everything on a zero offset, deduct 1 to make it 7611 and 7711.
The CEP product utilizes the same mechanism so also here open the same ports on the server.
There is in case of CEP another binary protocol with associated ports. In this case it is the 9611 and 9711 ports that need to be opened. You will see again the unsecure (9611) and secure ports (9711).
Hazelcast
Since we have a clustered setup, we need to enable communication between nodes in the cluster. In this case it is the API Manager (manager node) and the two workernode that need to communicate.
We start with a default setting of a port of 4500 for the manager node and two worker nodes at 4100 and 4200. So these ports need to be opened as well.
Distributed setup of API Manager
Since we have a distributed setup of the API manager, the ports they use for communication between the 5 components need to be opened up as well but when you follow this tutorial they will already be open. If you want to configure this: go the the api-mgt.xml or see the documentation online from WSO2. It is not rocket science but will take you some time to configure all the traffic between these components.
Load Balancer
A load balancer and its port offset are out of scope for this article but for any traffic to and from the load balancer the right ports need to be opened on the server where the loadbalancer is running (in case of a software loadbalancer) or the IP address / port for a hardware loadbalancer like F5.
Loads of ports
As you can see there are many ports that need to be opened on the servers but leaving unsecure ports open, especially when they are connected to the public internet is unwise. Hackers employ portscanners that will scan for open ports and try to see if there is one that they can use to get access to the machines and / or exploit vulnerabilities (i.e. holes in the software running) to the same effect.
If you have any questions about this blogpost contact us via the comments section of this blog. For more View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs. {{cta(‘d96cddee-168c-42a5-a0b6-00a670e766b7’)}}
