SSH traffic on one policy appears to be denied by a policy that is currently disabled. How is that even possible?

[pehlmanj]

I created a policy (number 21) that allows several types of traffic outbound (ssh, https, tcp 8989, tcp 61000 - 65535, and UDP 1024-65535).  All traffic seems to be passing except SSH, which is being blocked by policy number 25, which is supposed to be disabled.  During troubleshooting, it looked like policy 25 was responsible for denying my SSH traffic, so I disabled policy number 25 to continue troubleshooting, but when I look at the monitor, policy 25's name is being referenced as the reason the SSH traffic is being denied.  Is there something more to disabling a policy other than just highlighting the policy, and clicking the disable button?  The policy is "greyed out" so it looks like it's disabled, but my SSH traffic still isnt flowing.

[JayGolf]

Hi @pehlmanj ,

After disabling a policy, please commit your changes to the firewall. Once committed, the disable should be enforced for new traffic. 

[pehlmanj]

Sorry, I should have mentioned that I did commit the change.

[BPry]

@pehlmanj,

The only way that makes any sense is if you've modified defaults so that 'rematch sessions' is not enabled, or you didn't actually commit the change. If you've actually committed the changes the only way this makes sense is if you've disabled rematch sessions in which case you'll want to change that back to default and just enable it again.

[pehlmanj]

"Rematch sessions" is enabled. (It was never disabled).  And changes were committed.  The rule in question is showing up as "greyed out" but the monitor is still pointing to it as the cause of my SSH denials.