Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 267
  • Last Modified:

Cisco ACL interfering with SMTP

I cannot post configs of the router in question, I apologize for that. We are having an issue that when we apply an ACL to an interface it begins blocking traffic for what seems like no reason. The ACL only has one line permit ip any any. When it is applied in the inbound direction on an outside interface weird things begin to happen. An open RDP session to a server on the other side of the router is dropped, but the SSH connection to the router stays up. A mail marshall server we have goes through all normal smtp messages with the distant end MTA, but fails when the email payload is actually attempted to pass. When the ACL is removed, everything flows as normal again. I'm sorry for the vagueness of this question, attached is  a rudimentary diagram.
ACL-Problem.pptx
0
psychokraft
Asked:
psychokraft
  • 4
  • 2
3 Solutions
 
giltjrCommented:
What is the router model number and what IOS is it running?

Could you try adding the following to your ACL and see what gets logged?

deny any log
0
 
psychokraftAuthor Commented:
Off the top of my head its a 7206. I will have to get back to you with the IOS. I can add this detail: there are 4 routers serving domains that are nearly identical save for ip addressing. 2 of the routers experience this issue, while two of them do not. Except for the ip addressing the configs are virtually identical. When we look at the log with the permit ip any any we see the traffic that is getting dropped being permitted by the ACL.
0
 
giltjrCommented:
If you have 4 routers with the same basic config and two are having issues, I would look at the version of IOS and make sure they are all running the same exact level of IOS.

I would also make sure that the ACL in question is applied to an interface on the same exact model of line card.

If everything is the same, I would open a TAC with Cisco.
0
Lessons on Wi-Fi & Recommendations on KRACK

Simplicity and security can be a difficult  balance for any business to tackle. Join us on December 6th for a look at your company's biggest security gap. We will also address the most recent attack, "KRACK" and provide recommendations on how to secure your Wi-Fi network today!

 
psychokraftAuthor Commented:
I apologize for the delay. As of today I cannot access the devices due to the holiday but I will attend to this question. I want to make sure it was resolved before I accept an answer so that thsi issue can be properly documented for anyone experiencing this in the future.
0
 
psychokraftAuthor Commented:
My colleague at the remote site worked on this extensively and found the problem. The fact that the permit ip any any log (I forgot to mention the log) created a log for every packet meant that control plane traffic must have been being created at a large rate. A configured CoPP policy map was configured with a low value. When my colleague either removed the CoPP or the log statement, traffic began to flow again. I would not have though of this and it seems counterintuitive but that is what fixed it.
0
 
psychokraftAuthor Commented:
This solution points to logged traffic by the router as a source of control plane traffic. Future problems that may be encountered such as this should lead to an examination of the log statements at the end of ACL entries and any configured control plane policing or protection.
0

Featured Post

Lessons on Wi-Fi & Recommendations on KRACK

Simplicity and security can be a difficult  balance for any business to tackle. Join us on December 6th for a look at your company's biggest security gap. We will also address the most recent attack, "KRACK" and provide recommendations on how to secure your Wi-Fi network today!

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now