IBM Support

Verify a port is open

Troubleshooting


Problem

Verify the port is open from outside the machine

To check a port is open and reachable on a target machine, use any of the following commands:

curl -v <targetIP>:<portNumber>
nc -w 60 -vz <targetIP> -p <portNumber>
telnet <targetIP>:<portNumber>
nmap -Pn <targetIP> -p <portNumber>

Replace <targetIP> with the IP address or the hostname of the target machine. While not recommended to use hostnames instead of IPs, one can check the hostname resolves to the correct IP by running `nslookup hostname`.
Curl could be used to test different protocols, for example: `curl -v telnet://<targetIP>`, `curl -v http:://<targetIP>`, `curl -v https://<targetIP>`, `curl -v smtp://<targetIP>`

If there are any firewalls devices or cloud-based firewalls between the source and target machines, check those are configured to allow traffic from the sources to the target on the port being tested.

If the connectivity fails when tested with the utilities above, one can use the following diagnostics utilities to display the path/route and find out the last device the connectivity is blocked at:

tracepath <targetIP>/<portNumber>
traceroute <targetIP>
mtr -r -w -c 100 <targetIP>

Verify the port is open within the machine

As a root user use the following command to verify the active TCP connections, which ports/daemons are listening and on what interfaces:

netstat -nlp | grep ':portNumber'

Replace `portNumber` with the actual number of the port being verified.
Alternatively, if one doesn't remember the port number a process was configured to listen on, one can use the following command to display the process that are currently listening:

netstat -nlp | grep -i listen

If there is not active TCP connection listening on the port, check the service status using `service --status-all` or check the process is running using `ps -aux`.
If the daemon is listening (status Listen/Listening/Established), but the port can't be accessed from outside the machine, check the firewall as defined within the machine:

iptables -L

Verify that no packets are being dropped or rerouted for the port or the sour IP address being tested. By default, no rules should be enabled, for example:

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Other troubleshooting hints:
The iptables log data is captured in syslog (by default the /var/log/messages log file). The firewall log messages can be displayed using: `sudo tail -f /var/log/messages | grep FIREWALL`. Also, there could be useful network related messages in the kernel buffer diagnostic messages (run the command `dmesg` to see it, the log is available by default in /var/log/dmesg).

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB76","label":"Data Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCR56","label":"IBM DataStax Enterprise"},"ARM Category":[{"code":"","label":""}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)"}]

Historical Number

ka06R0000006CAEQA2

Document Information

Modified date:
30 January 2026

UID

ibm17259133