Ports/protocols needed for Client installation on unmanaged servers
I have a situation where the servers that need to have the Opsware client installed are sitting behind two firewalls, we ahve already opened ports 3001 & 1002 for the client/server comms.
What I am trying to do is scan a host (by IP) and then want to install the client remotely, at the moment this fails to find the client scanned and I do not know which ports/protocols I need to open to get this working. I do not have access to the Firewalls to see the packets so cannot troubleshoot the issue this way.
If anyone can tell me the ports needed then I can get them opened and test
Re: Ports/protocols needed for Client installation on unmanaged servers
Thanks, unfortunately I cannot access that post in the support forum, i won't be able to get access as the IT support who manager HPOO/HPSA for my company won't give me the necessary details (long story!) Just like they won't help me out with the port numbers i need.
Is there any change you can post the information here or PM me with it please?
Re: Ports/protocols needed for Client installation on unmanaged servers
When Opsware Discovery and Agent Deployment (ODAD) is used to scan a network range, it invokes the nmap network mapping utility to identify hosts in the given IP range(s). By default, ODAD runs nmap in a mode where it:
Uses an ICMP echo request (“ping”) and a TCP ACK packet to port 80 to determine if a host appears to be at the given IP address. If no response is returned, nmap moves on to the next IP address. Otherwise, nmap:
Looks up the IP address in DNS and attempts to map it to a host name. If the lookup is successful, the host name is shown in the Opsware SAS client; otherwise, the IP address is shown.
Attempts to open TCP connections to ports 22 (ssh), 23 (telnet), 137 (NETBIOS name service), 138 (NETBIOS datagram service), 139 (NETBIOS session service), 513 (remote login), 514 (remote shell), 1002 (Opsware Agent), 80 (HTTP), 443 (HTTP over SSL), 25 (SMTP), and 3389 (Windows Terminal Services). Any ports that can be used to log in to the device are noted by the Opsware SAS client. Additionally, if port 1002 appears to be open, the device is assumed to be already managed by Opsware, and deployment to that host is not allowed in the Opsware SAS client.
If nmap found at least one open and one closed port among the ports scanned, it will attempt to detect the OS running on the host. It performs this task by sending a series of specially crafted packets to the host and observing the responses. Since each operating system implements the TCP/IP protocol stack slightly differently, the set of responses to these packets forms a “fingerprint” that can be used to try to guess the operating system of the remote host. If the set of responses matches one of the fingerprints in the nmap database, ODAD shows this information in the “Detected OS” column.
Firewall Configurations that can interfere with ODAD Scanning DNS Unavailable
If nmap is unable to contact a DNS server to map the IP address into a hostname, the “Name” column will be blank, but other ODAD functionality will not be affected.
Blocked ICMP echo request (ping) packets
If your firewall blocks ICMP echo request packets, then ODAD may not be able to detect hosts on the other side of the firewall. To resolve this situation, you might add a firewall policy that allows ICMP echo requests only from the IP address of the Opsware Gateway performing the scans.
Alternatively, you can add the option –P0 to the nmap scan parameters (Tools -> Options -> Unmanaged Servers -> Advanced -> nmap parameters). This option configures nmap so that it will continue to probe an IP address even if no ping response is received. This will slow down network scans, however, since nmap must spend additional time on IP addresses where there is no host.
Too many blocked ports
If your firewall blocks most or all of the ports that ODAD scans, it might be impossible to detect the presence of hosts on the other side of the firewall. In some cases, nmap might be able to determine that something is at a particular IP address, but could not locate one open and one closed port to perform OS detection. In this case, the “Detected OS” column will be blank.
Firewalls that perform stateful packet inspection are sophisticated devices that observe the setup of network communication between hosts and can perform complicated filtering that a stateless firewall cannot perform. Examples of stateful packet inspection firewalls include the Checkpoint Firewall-1 and the Cisco PIX firewall. There are many other stateful firewalls, however.
For example, a common use for stateful packet inspection is to block incoming TCP packets that do not perform the standard 3-way TCP handshake. Normally, a client that wishes to establish a connection to a server sends a TCP SYN packet. The server responds with an TCP SYN packet, and the client response with a TCP ACK packet. A stateful packet inspection firewall can block ACK packets from clients if it has not seen a corresponding SYN packet, or if the payload of the ACK packet is incorrect.
There is quite a bit of variation in how different OS vendors implement error handling in their TCP/IP stacks, so nmap sends a series of “incorrect” packets to the remote host during the OS detection phase and observes how the remote host responds. After it has collected the responses, it matches them against a database, and provides the best matches, which ODAD displays in the “Detected OS” column.
If a stateful packet inspection firewall filters out these packets, then some or all of the information nmap needs to detect the remote OS may be missing. If this happens, nmap may not be able to determine the OS at all, or it may not be able to definitively match a single entry in its database. In that case, ODAD may show several different operating system names in the “Detected OS” column.
Stateful Packet Inspection Firewall – firewall responds instead of host
Some of the more sophisticated stateful firewalls will actually perform the TCP 3-way handshake on behalf of the protected server, and only “hand off” the connection to the server once it has been correctly established. If ODAD is asked to scan a range of IP addresses protected by such a firewall, it may conclude that all of the hosts behind the firewall are running the same OS, since the firewall itself is crafting the response packets to the nmap probes, rather than the hosts.
Strategies for Improving ODAD Scan Results
If possible, deploy Opsware in such a way that it does not have to traverse a firewall to connect to the servers it manages.
If your network security policy prohibits this, then consider deploying an Opsware Gateway in each firewalled compartment. ODAD can scan from any Opsware Gateway in a core or satellite; this technique allows Opsware to scan from within the firewalled compartment.
If this is not a practical solution, perhaps because it would not be cost-effective to deploy a separate Opsware Gateway into each firewalled compartment, consider changing the firewall policy so that the Opsware Gateway can establish the connections and send the packets it needs to send to accomplish OS fingerprinting.
As a last resort, it is always possible to deploy Opsware Agents manually, by copying the Agent Installer executable to each host and running it at the command line.