I see these messages from time to time when an Exchange 2000 server has a stuck message in its queue. The part in the parentheses immediately following "Invalid SMTP command" varies. For instance, on a previous occasion it was (content-cl). Regardless of the text the total character length is always 10 characters.
Additional information: IOS (tm) C806 Software (C806-K9OSY6-M), Version 12.3(1a), RELEASE SOFTWARE (fc1). The problem only seems to occur when the ex2k machine attempts to send mail to a non-esmtp machine. In some cases it reverts to a successful HELO and the session is established. But with some servers even the HELO won't work and the message remains stuck in the queue. I've run a packet sniffer on the line and the packet contents all look normal. Does anyone know why the firewall is flagging supposedly bad smtp commands?
I have not yet put a sniffer on the outside side of the firewall. Does anyone know if the firewall is actually allowing these supposedly bad packets out?
I would be willing to bet that you have the following configured:
ip inspect name smtp
With this configured, CBAC inspects all SMTP packets for illegal commands. Any packets with illegal commands are dropped, and the SMTP session will hang and eventually time out. An illegal command is any command except for the following legal commands:
For more info, please refer to the following (The Bible for CBAC info):
Thanks for your reply. You are absolutely right, I do have the following configured:
ip inspect name smtp
Additionally I am have read (several times, actually) "The Bible for CBAC" and believe that CBAC is responsible for blocking packets, although as I mentioned I'm still not sure whether it's the outbound or return traffic that's being blocked.
At the foundation I believe there may be a "feature" (read "possible bug") in the CBAC implementation that is incorrectly identifying portions of packet payload as being illegal smtp commands. I've been forunate enough to capture live packets traces during this CBAC event chain. Using snort I've logged the exchange between smtp servers in binary tcpdump format. It strikes me that this would be invaluable real-world data for the Cisco developers responsible for CBAC. Is there an interest in my providing this trace?
Absolutely, your trace would be of interest to us. As you mentioned though, it is difficult to tell based on the log messages whether the packets that we blocked were inbound or outbound. In most cases where SMTP inspection is config'ed, there is no way (feasible) sniff the wire on teh outside (assuming some sort of WAN connection). However, if you have ethernet on both sides (or the ability to sniff WAN links), then open a TAC case and give us the info collected. I have been suspecting a "feature" in the SMTP inspection code for sometime but I have never had anyone willing/able to provide the info. Most people just turn off SMTP inspection and move on...sad but understandable.
OK Scott, let's move ahead on this. Perhaps it's time to take the dialog offline. Why don't you send me an email message and we can coordinate (i.e. I've never opened a TAC case before and wouldn't know where to begin). I'll be traveling for the next week or so but upon my return I'd like to investigate further. I'll even try to set up a sniffer on the WAN side of the router as I've identified a seemingly consistent/reproducible mail server for raising this event.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...