firewallnetworkingsolaristcp
We will be deploying a new application to a Server and the application will be listening on port 8443. We have asked Network team to open the firewall for the port 8443 on that server before deploying the application. There is no application currently listening on that particular port on the server.
Is there anyway i can make sure the firewall is opened for the port 8443
OS: Linux / Windows
On the first question, maybe the service does not wait for interactive input. There could be other explanations, too. On the second, nmap can be used to test the firewall. There are many options.
Scan the first 1,000 ports (default):
nmap -v -A -PN hostname.domainname.com
Or perhaps a specific range:
nmap -v -A -p 10000-11000 -PN hostname.domainname.com
It's part of the TCP (or UDP, etc.) header, in the packet. So the server finds out because the client tells it. This is similar to how it finds out the client's IP address (which is part of the IP header).
E.g., every TCP packet includes an IP header (with source IP, destination IP, and protocol [TCP], at least). Then there is a TCP header (with source and destination port, plus more).
When the kernel receives a SYN packet (the start of a TCP connection) with a remote IP of 10.11.12.13 (in the IP header) and a remote port of 12345 (in the TCP header), it then knows the remote IP and port. It sends back a SYN|ACK. If it gets an ACK back, the listen call returns a new socket, set up for that connection.
A TCP socket is uniquely identified by the four values (remote IP, local IP, remote port, local port). You can have multiple connections/sockets, as long as at least one of those differs.
Typically, the local port and local IP will be the same for all connections to a server process (e.g. all connections to sshd will be on local-ip:22). If one remote machine makes multiple connections, each one will use a different remote port. So everything but the remote port will be the same, but that's fine—only one of the four has to differ.
You can use, e.g., wirehsark to see the packet, and it'll label all the data for you. Here is the source port highlighted (notice it highlighted in the decoded packet, as well as the hex dump at the bottom):
Best Answer
If you want to see if you can form a TCP connection from a remote machine, get OpenCSW installed on that and the target machine, and install netcat on both. This is the syntax for using netcat to test TCP connections:
nc -vz targetServer portNumFor example to check SSH on "homeServer1":
nc -vz homeserver1 22That enables you to test TCP-level connectivity from the remote system. Netcat can also be configured to listen on a port rather than act as a client. To get it to listen on TCP/8443:
On the server that will house the application:
nc -l homeserver1 8443On a machine that sits outside the firewall:
nc -vz homeserver.fqdn 8443This is an example of a successful execution:
A failed execution: