SIM unable to recieve traps from DMZ

[tsl_2]

Thanks James, the ports are opened fine.
We have actually full IP access right now between the servers for testing purposes...but no luck.
Wierd one indeed!

[James ~ Happy Dude]

Believe U me, even I am curious to whats wrong then ?!!!!!

Seems so close... yet so far from solution !

Is there any local Security policies etc that may effect traps ?

Or, just wait for a day or more, before U re-install SIM ... see if anyone else has a different view to this.

James.

[Rob Buxton]

OK, this is happening on all servers in the DMZ?
In HPSIM how does the server show up, just as an IP address or as a resolved name?
Also does it show up as a Server type or is it "Unknown" / "Unmanaged"?

I'm really just guessing more around DNS as the issue.
I'm not too sure of how it would happen, but if the trap is apprearing to come from a name or IP address HPSIM knows nothing about there may be an error.

Have you looked at just the "Events" view itself to make sure an event isn't being misreported against another device?
You could event try extracting the data directly from the HPSIM database to see if anything is there.

With the trap watcher utility you use, does that contain details of the Traps suspected origin? Again does that match what HPSIm has recognised as the server?

[tsl_2]

Hi Rob, yes it's the same issue with all DMZ servers as far as I know. In the beginning I thought it was only because we hadn't opened up 162/udp, but as said it's not the case anymore.

All servers/agents are registered in DNS. At discovery we use the FQDN. The SIM server has all the different domain names in it's search order so it's able to lookup host23 -> host23.somedomain.tld

In SIM it's discovered with FQDN and has the correct hardware (server/model) listed along with the IP.

Yesterday I installed NET-SNMP as the trap listener (instead of Microsofts version) and in the snmptrapd.log I can see the test trap from a DMZ server registered fine (but not in SIM event view). In the log it's registered with only the hostname and not the FQDN (i.e ...[IP Address]...SNMPv2-MIB::sysname.0 = STRING: HOST23 SNMPv2-SMI...). Maybe this is causing problems? We use NAT for DMZ servers so they have an internal IP but SIM server needs to access it on it's external IP. The FQDNs all points to the DMZ servers external IPs.
In the trap, both IPs are listed (internal/external). But if this was a problem, wouldn't the event still show in the all events view?

I have checked the local security policies on the SIM server and they are no different from i.e the eventmanager server. I tried to redirect the snmp trap directly from the DMZ server to the eventmanager (not to SIM server first) and it worked fine. The eventmanager is on the same subnet as the SIM server.

pew, as a workaround I guess I could have all DMZ agents using NAT to trap directly to the eventmanager?! Still, it would be nice to have the SIM do all the trap forwarding to be consistent.

[Wilbert Chin]

You've eliminated the firewall as an issue. It looks like you're onto something with the NAT issue. Since you are NATing, all DMZ servers are sending traps with the same IP and a short name instead of FQDN. DNS won't be able to match up the single IP to each DMZ server. DNS can expand on the short name but you end up with an IP that doesn't match the NAT IP.

It sounds like the traps from the DMZ servers are not sending back the matching information for a server in the SIM database. Therefore, SIM does nothing with the trap that it receives. Have you tried deleting the server record and done a manual discovery of one of the DMZ servers?

You might also try a manual discovery by the NAT IP address and then test the traps again. These steps should eliminate or confirm a NAT / DNS issue.

[tsl_2]

Yes, the NAT/PAT seems to be the issue. I found a DMZ server that used it's actual external IP and not a private one, this trap worked!

It's not possible for the SIM server to reach the DMZ servers using NAT/PAT on their internal IPs, only their respecive external IPs.

It's unfortunate that SIM is having a hard time to cope with this setup. I have therefore decided to let all agents trap directly to the eventmanager instead, but to have SIM for configuration and hardware problem management.

Thanks all for your input, it's much appreciated.

[Rob Buxton]

The issue does seem to be that the trap appears to originate from a server HPSIM knows nothing about.

In the Event Filter settings you can Accept Unregistered Events. But looking at the screen further and it seems to be about accepting traps from discovered devices. In effect HPSIM is getting traps from undiscovered devices.

Is the subnet range for the internal Nat'd addresses in the Discovery range? Maybe the fix is to try and get HPSIM to discover these devices on the same address range as the traps are appearing to originate.

[tsl_2]

hmm, I think your are right about the "Unregistered events" setting. The DMZ servers are registered fine but when the traps come in, SIM cannot match the IP to a discovered device (though both IPs (internal/external) are in the trap).

I'm not able to discover the Nat'd addresses from the SIM server. We have to use their external IPs in current setup.

Thanks
-tsl-