6 Replies Latest reply on May 7, 2014 9:28 AM by tcbene

    Firewall Enterprise 8.3.2 P02 snmp traps fails

    tcbene

      I have not been successful in receiving traps from MFE version 8.3.2P02.  When I look at the traffic being sent by the firewall it missing the encryption informaiton.  Has anyone been successful in sending traps with MFE version 8.3.2P02 or any 8.3 version?

        • 1. Re: Firewall Enterprise 8.3.2 P02 snmp traps fails

          Hello,

           

          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,

           

          Matt

          • 2. Re: Firewall Enterprise 8.3.2 P02 snmp traps fails
            tcbene

            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. 

            • 3. Re: Firewall Enterprise 8.3.2 P02 snmp traps fails
              sliedl

              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.

              • 4. Re: Firewall Enterprise 8.3.2 P02 snmp traps fails
                tcbene

                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.

                 

                Message was edited by: tcbene on 5/6/14 4:11:47 PM CDT
                • 5. Re: Firewall Enterprise 8.3.2 P02 snmp traps fails
                  sliedl

                  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)

                   

                  4. Discovery

                     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.

                  • 6. Re: Firewall Enterprise 8.3.2 P02 snmp traps fails
                    tcbene

                    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.