snmp-trap_default_ did not enter VPN.

[Thomas_Eichelbu]

Hello Ceckmates,

following weird scenario.

we found out that the built in service "snmp-trap_default_" did not enter VPN at all, it was always sent in clear text, it never got encrypted. There were no exclusions inside the VPN Community or any other exclusions.

in the screnshot you see two identical service definitiions snmp-trap_default_ and snmp-trap.

I bet the snmp-trap_default_ and all other service with a "_" were created after the R80.10 update ...

After hours of troubleshooting we came to the idea to uncheck the "match for any" for snmp-trap_default_ and set it on snmp-trap and replace the snmp-trap_default_ from with snmp-trap in all rules.

Then it worked ...

Has somebody an explanations for this?
Altough the issue is solved it would be great to unterstand what was wrong..

Best regards
Thomas.

[PhoneBoy]

The renamed service is because you had, at some point before upgrading to R80.10, modified the snmp-trap service from it's default settings.

In R80.10, this is not allowed, and previous services are "renamed."

My guess is that your snmp-trap_default_ service is different from the default one in R80.10, which caused the issue somehow.

[Miroslaw_Kozmic]

Hi Thomas,

We've had issues with the snmp-trap service after upgrading to R80.10, but it has been much worse in our scenario. Have you checked if the snmp-trap_default_ has been configured with a protocol signature?

In our case, because we've had Match By Port set to "Any" all traffic was matched to this service. Also, we've had "Accept Replies" disabled in this service. Because all UDP traffic has been matched to this service none of the replies were accepted, including DNS and LDAP traffic which caused great outages in the network.

When we disabled this service everything started working again. We configured other services in the same manner - no issues were visible. It was just snmp-trap that for some reason matched more traffic than it should. We tried to find the cause of the issue with TAC engineer but eventually RnD told us that it is "expected bahavior" so we've been left with no answer...

Best Regards,

Miroslaw

[Thomas_Eichelbu]

Helllo Miroslav,

well yes this is interessting.
yes the service snmp_trap_default_ was totaly identical to snmp_trap service, both were with protocol signatures.
I know from the past that sometimes it is usefull to duplicate a service and work with the duplicates.
So anyway this issue was solved fast and caused only minor downtime, because only snmp trap were affected at all.

i just wanted to know if this is a known problem, and if there is a technical explanation.

best regards
Thomas.

[PhoneBoy]

If I had to guess, it's something to do with the underlying inspect handler.

An official explanation would have to come from someone in R&D.

If, for some reason, you do need to have a duplicate of this snmp_trap service, it's worth a ticket to the TAC.