Re: Ports/protocols needed for Client installation on unmanaged servers (2080 Views)
Reply
Occasional Contributor
bobmarsh
Posts: 5
Registered: ‎06-29-2011
Message 1 of 6 (2,086 Views)
Accepted Solution

Ports/protocols needed for Client installation on unmanaged servers

Hi, 

 

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

 

thanks in advance to anyone that can help

Please use plain text.
Advisor
Ricardo Carrillo Cruz
Posts: 24
Registered: ‎01-02-2009
Message 2 of 6 (2,084 Views)

Re: Ports/protocols needed for Client installation on unmanaged servers

Hi Bob

 

It depends on the OS of the unmanaged servers:

 

Unix -> You can deploy with SSH/Telnet/Rlogin

Windows -> You deploy via NetBIOS

 

By default, SA Client uses the IANA assigned ports for the aforementioned protocols.

 

You can check them out if you go in the SA Client to Tools->Options->Unmanaged Servers->Protocols .

 

HTH

 

Regards

 

HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
Please use plain text.
Advisor
mattbowden
Posts: 15
Registered: ‎04-19-2011
Message 3 of 6 (2,080 Views)

Re: Ports/protocols needed for Client installation on unmanaged servers

I posted this the other day in the "Server Automation Support Customer Forum" - if you don't have access to this, you should get it.

 

http://h30499.www3.hp.com/t5/Server-Automation-Support/bd-p/server-automation-support-customer-forum

 

Here is a good KM on it.

  • KM630394 (just be sure to add 445/tcp to the list for Windows)



Please use plain text.
Occasional Contributor
bobmarsh
Posts: 5
Registered: ‎06-29-2011
Message 4 of 6 (2,072 Views)

Re: Ports/protocols needed for Client installation on unmanaged servers

Thanks Ricardo, they are windows hosts, i will open up Netbios and see if that resolves the issue.

 

Please use plain text.
Occasional Contributor
bobmarsh
Posts: 5
Registered: ‎06-29-2011
Message 5 of 6 (2,068 Views)

Re: Ports/protocols needed for Client installation on unmanaged servers

Matt,

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?

Same for the KM article?
Please use plain text.
Advisor
mattbowden
Posts: 15
Registered: ‎04-19-2011
Message 6 of 6 (2,064 Views)

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.

Stateful Packet Inspection Firewall – filtered packets

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.

Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation