OK.
If I understood correctly, your snmpd.conf file should now have both IP addresses on com2sec lines:
com2sec mynetwork 172.16.5.57 FusAfiL2IQs
com2sec mynetwork 172.16.184.34 FusAfiL2IQs
Now, if you try snmpwalk from the Solarwinds server, with the logging enabled at the HP-UX server, what happens?
Do you see messages like "Received SNMP packet(s) from UDP: [172.16.5.57]:<some port number>->[0.0.0.0]" in the log at the HP-UX server, or not?
If not, it may be a network communication issue in getting the packets from the Solarwinds server to the HP-UX server.
If the messages are appearing in the log and you are using the correct community name at the Solarwinds server, then it is probably another network communication issue: something is preventing the answers of the HP-UX server from getting back to the Solarwinds server.
If you see lines like this:
Connection from UDP: [172.16.5.57]:<some port number>->[0.0.0.0] REFUSED
... then your net-snmpd is receiving the query from the Solarwinds server, but rejecting it because the source IP address is not in the allowed list. The net-snmpd may be compiled with the "libwrap support" feature enabled: in that case, you should add a line like this to your /etc/hosts.allow file (or create the file if it does not exist):
snmpd: 127.0.0.1 172.16.184.34
If the log seems to indicate that net-snmpd is receiving and accepting the query from Solarwinds, or if no query from Solarwinds seems to be received at all, it might be a firewall issue.
SNMP is an UDP-based protocol. With UDP, allowing communication from A to B does not automatically guarantee that replies from B back to A are allowed too. This is because some UDP-based protocols are truly one-directional and won't ever reply. (For example, the syslog remote logging protocol.)
With TCP-based protocols, sending something from A to B always requires that B can send acknowledge messages back to A, so if communication from A to B is allowed, replies from B to A must be automatically allowed too.
Most modern protocols use TCP, so sometimes firewall administrators assume that the TCP behavior is the standard for all protocols, and forget that UDP-based protocols can be different. Some firewalls can automatically allow the replies with UDP protocols too, but that requires that the firewall "knows" how the UDP-based protocol is supposed to behave. A SNMP protocol in standard port 161 might have its responses handled automatically, but using SNMP with a custom port 1161 might need some special settings, or just a separate firewall rule like:
allow UDP packets from port 1161 of 172.16.184.34 to any port of 172.16.5.57
The usual firewall rules are like:
allow <protocol> from any port of <source IP> to port <number> of <destination IP>
so the net-snmp in a custom port might need a rule that works in a reverse sense. Most firewalls allow this, but the firewall administrator might not be able to use his/her "standard template" in defining the rule for net-snmp replies, so mistakes are more likely than usual.
The firewall might be implemented in software too: an IPFilter on the HP-UX system or a Windows firewall on the Solarwinds system might be causing the problem. If a HP-UX system has IPFilter installed and configured, its configuration files should be in /etc/opt/ipf. If that directory does not exist or is empty, you can be reasonably sure you don't have IPFilter active on your system.
MK
