Duplicate services - which will be used?

[Martin_Oles]

Hi,

recently I came across behavior, where supposedly permitted traffic is dropped by protocol handler. In my case I do do have defined duplicated service objects for snmp, udp/161. First is default service object snmp, port udp/161 with no Protocol Type set. Second service object is also port udp/161 with Protocol Type: SNMP_V3 , both objects are set "Match for Any", And both objects are used in a rule, which permits SNMP for monitoring.

Some SNMPv2 packets are permitted when matching rule, but dropped by protocol handler:

;[cpu_2];[fw4_3];fw_log_drop_ex: Packet proto=17 10.20.30.40:47940 -> 20.30.40.50:161 dropped by fwpslglue_chain Reason: PSL Drop: ASPII_MT;

Being aware, that such is not ideal situation, but still I am wonder, how INSPECT will decide, which service parameters will be used for traffic? How then is handling traffic in situation, where is duplicity in service objects exists and in a rule is used "any" for service?

Thank you for tips to documentation or SKs related.

[G_W_Albrecht]

Duplicate services are not supported and should not be used at all !

[PhoneBoy · Accepted solution]

Depends on what service is in the rule that matches the connection.
If the rule has a service of "Any" then the service that has "Match for Any" checked will apply.
And yes, you can only have one service defined with a given port that is configured with "Match for Any" else you will get a a compilation error.

[Martin_Oles]

Both services are having currently "match for any" set. I am aware, that such is not supported, but rather big environment and complex rule is profound for such. Surprisingly SNMPv2 traffic is dropped by protocol handler as not matching SNMPv3 even if I have created dedicated rule, where is only used SNMPv2 service object without any protocol handler.

Not being fan to elaborate on production system I will try to re-create it in lab environment.

Dropped traffic is matching rule, where as service are both service objects used with udp/161.

[G_W_Albrecht]

If you are already aware that such a configuration is not supported and will not work, all is good !

[PhoneBoy]

That's bound to cause some issues and is definitely worth a TAC case.
In a default configuration in R80.x at least, specific services for SNMPv3 and SNMPv2 do not exist.