SNMP being secretly dropped by "fwpslglue_chain Reason: PSL Drop: ASPII_MT"

[Darren_Fine]

Hi ,

Had an interesting problem today - snmp was not working through an R80.10 firewall with JHF 112.

All the logs showed it was being allowed through on both the security policy and the application control layer.(which led most of the firewall admins to tell the network monitoring guys that its their issue...hahaha)

However when this was escalated I ran a fw ctl zdeug drop and low and behold..... found the infamous "dropped by fwpslglue_chain Reason: PSL Drop: ASPII_MT" for this traffic.

Since I have encountered this error before and it seems it can be for numerous blades I logged a call to see if TAC could give me a good idea on how to track this down .(thought maybe they would have some great way to isolate what can cause this by now..)

The only idea they had was to install latest JHF 😞

Anyhow - after doing that in a change window (the new JHF did not help ) - I tried switching off IPS which made no difference. I then switched off application control and what do you know - snmp started working. 🙂

In the end the solution was to make a rule higher up in the Application control layer rulebase allowing this ,

(even though there was a rule further down allowing this and the firewall logged as being allowed on that rule.... very misleading....)

So I just thought I would share this in case this assists anyone else out there ...

Regards

[Alessandro_Marr]

Hello, looking for any domain object without FQDN flag marked.... this situation in r80.10 bring a lot of problems... 

[PhoneBoy]

SNMP is one of those services that's handled in the firewall (meaning it doesn't require App Control).
Did the drop message provide a clue about what rule might be the culprit?

[HeikoAnkenbrand]

Hi @Darren_Fine 

In firewall rulebase, the service may be evaluated before evaluating the source or the destination.

Workaround:

1) Create a new customer service for SNMP and set the protocol type to "none".
     Now unchecking the box 'Match for 'Any'' in the new customer service.

2) Use the new customer service in the rule.

3) Install policy

More to PSL/PXL can you read here:

R80.x Security Gateway Architecture (Logical Packet Flow)

[Darren_Fine]

Hi Guys,

Thanks for reading my post and for the reply 😃

@PhoneBoy there was only allows in the normal firewall logs for both firewall rules and application rules (its a legacy rulebase so they in different layers). I only saw the drop when doing the debug ..with the error mentioned in the subject.

Creating the allow snmp rule in the application control layer solved the problem so not sure how it would not require application control ? 😉

@HeikoAnkenbrand it did look like the rule was evaluated and found to be allowed (at least this is what the logs said). I did see a knowledge base that mentioned the steps you listed but some snmp traffic was working fine so I did not go that way .. As mentioned the addition of an application control rule for snmp seems to have fixed the issue. 

So its definitely working from the application control rule addition but I am now confused since you guys seem to think this should not have been the solution 🤔

[PhoneBoy · Accepted solution]

App Control will be involved if there were other rules before the SNMP rule that require App Control.
This applies even if the final matching rule doesn't require it. 😁
By putting a specific SNMP rule at/near the top, you avoid this.

[HeikoAnkenbrand]

Hi @Darren_Fine 

@PhoneBoy  was right.

I had the same problem with customers and the following sk97876 helped.   

But when everything's solved, that's great. 😀