I tried to find if there were any known issues, did not find any. Would you be able to send a screenshot of your SNMP config? Feel free to remove any private information. There are two screens I am interested in, the SNMP Agent screen under Monitor and the "SNMP v3 Trap Settings" section.
Thanks for responding. I cannot send a screen shot. I can tell you I am using snmp version3 with auth type SHA-1, Privacy Protocol AES, Security level is AuthPriv. This is for both the SNMP v3 users and traps. I am only allowing SNMP v3 protocols, and have no community string. When I test the credentials from the mgmt worksation (ip listed under trap destinations) authentication is good.
The first couple packets coming from the firewall will not be encrypted. They are to discover the EngineID of the trap receiver you are about to send traps to. If the trap receiver does not reply back the firewall will not send traps to it.
Thanks for responding. Comparing my wireshark capture to the snmp message format, In the get-request sent by the firewall I can see all the common data in the packet, but all of the security model information is missing. This includes the msgAuthoritativeEngineID, msgAuthenticationparameters, msgPrivacyParameters, ContextEngineID, ContextName. So basically the managment station doesn't know how to decrypt the message once it receives it because none of the encryption information is listed.
This from Chapter 4 of the 'User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)', RFC 3414 (http://tools.ietf.org/html/rfc3414#section-4)
The User-based Security Model requires that a discovery process
obtains sufficient information about other SNMP engines in order to
communicate with them. Discovery requires an non-authoritative SNMP
engine to learn the authoritative SNMP engine's snmpEngineID value
before communication may proceed. This may be accomplished by
generating a Request message with a securityLevel of noAuthNoPriv, a
msgUserName of zero-length, a msgAuthoritativeEngineID value of zero
length, and the varBindList left empty. The response to this message
will be a Report message containing the snmpEngineID of the
authoritative SNMP engine as the value of the
msgAuthoritativeEngineID field within the msgSecurityParameters
field. It contains a Report PDU with the usmStatsUnknownEngineIDs
counter in the varBindList.
Thanks for responding and the link. I reviewed the information and then went back to the wireshark capture to compare a network device which is sending traps that the mgmt station processes and the firewall. What I found was the firewall is sending a get-request, whereas the other network device does not send a get-request is sends encryptedPDU: privkey unknown. Actually none of the other network devices which are sending snmpv3 are sending get-request, and the mgmt station is processing the snmptrap just fine. This is why I believe the firewall is not sending standard snmpv3 traps. It would be great if someone running 8.3.2P02 had traps configured and working. I believe this is a bug in 8.3.2.