Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

Inconsistent Behavior in FWSM Rules

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!

Cisco Employee

Re: Inconsistent Behavior in FWSM Rules

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.


New Member

Re: Inconsistent Behavior in FWSM Rules

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?

Cisco Employee

Re: Inconsistent Behavior in FWSM Rules

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.

New Member

Re: Inconsistent Behavior in FWSM Rules

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.

Cisco Employee

Re: Inconsistent Behavior in FWSM Rules

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.

CreatePlease to create content