topic Re: Inconsistent Behavior in FWSM Rules in Network Security

Inconsistent Behavior in FWSM Rules

brobson — Mon, 11 Mar 2019 16:42:26 GMT

We have had two incidents with firewall rules recently. First, we had an access rule that was not working. On a whim, we moved it to the top of the list. It began working. We moved it back down to the bottom of the list. It continued to work.

Today, a rule that had been working stopped working the way intended. There is a rule that allows my workstation to talk to a server on ports 2001 and 2002. Today, the FWSM would allow communication via port 2001 but denied communication via port 2002.

Has anyone else experienced similar behavior on their FWSM? We are running version 4.0(4). Thanks!

Re: Inconsistent Behavior in FWSM Rules

Panos Kampanakis — Tue, 24 Nov 2009 19:33:14 GMT

There are no known similar ACL issue in FWSM 4.0.4.

Maybe it was that there was a conn established after moving the rule down and it continues to work until the conn timed out.

Can you check what the logs say for the 2002 port traffic?

These should tell us id the rule is denied by the ACL and on what rule.

Re: Inconsistent Behavior in FWSM Rules

Kureli Sankar — Tue, 24 Nov 2009 22:36:08 GMT

Are there any explicit deny lines in this acl? Pls. grep for all the denies and see if any of which would have denied the flow when this acl was placed in the bottom.

sh access-l blah | i deny

Like PK says when you moved it to the top it worked and continued to work even after you moved it back down until it timed out after which it fails again.

Logs are your best friend.

Enable logging

conf t

loggin on

loggin buffered 7

sh logg | i x.x.x.x where x.x.x.x is the IP address of the host that is getting denied.

Re: Inconsistent Behavior in FWSM Rules

brobson — Wed, 25 Nov 2009 16:46:23 GMT

Re: moving the rule up in the access list. It makes sense that, once the connection was established, it continued to work after we moved it back down in the list. But why did we have to move it up to get it to work in the first place?

Re: Inconsistent Behavior in FWSM Rules

brobson — Wed, 25 Nov 2009 16:54:19 GMT

Re: moving the rule up in the access-list. There is only one explicit deny at the end of the list. The new rule was added above the explicit deny.

I'm more concerned about the second issue. We had a rule that was working for over a week when the firewall suddenly starting denying some of the traffic specified by the rule. The rule said, allow any workstation to access server X on ports 2001, 2002 and 2500. On Monday the firewall continued to allow traffic on ports 2001 and 2500 but started explicitely denying traffic on port 2002.

The rule is in the middle of the access-list. The only deny is at the end of the list. No changes had been made to the access list. The only way I could get it to work was to separate this into three separate rules, one for each port.

Re: Inconsistent Behavior in FWSM Rules

Kureli Sankar — Wed, 25 Nov 2009 17:38:48 GMT

That does sound strange. To further address this issue we need to see the output of

sh access-list

when the flow fails as well as the logs denying the flow indicating acl blocked.

Pls. enable logging and see what it says when the flow breaks. I have not heard of acls going missing after a week of being there and the fact that you have to use 3 lines for each port instead of object group.