{"id":190,"date":"2009-11-26T20:40:07","date_gmt":"2009-11-26T19:40:07","guid":{"rendered":"http:\/\/blogs.oucs.ox.ac.uk\/networks\/?p=190"},"modified":"2009-11-26T20:46:15","modified_gmt":"2009-11-26T19:46:15","slug":"cisco-firewall-smtp-fixup-considered-harmful","status":"publish","type":"post","link":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/2009\/11\/26\/cisco-firewall-smtp-fixup-considered-harmful\/","title":{"rendered":"Cisco firewall SMTP &#8220;fixup&#8221; considered harmful"},"content":{"rendered":"<p>This issue is old and familiar to us, and crops up about once every six months or so. I thought it might help to document the situation more publicly.<\/p>\n<p>On Cisco firewalls (PIX or the newer ASA), various protocol inspection engines are available. Generally, they assist in tracking connections of IP traffic through the firewall. That is, for a protocol such as FTP various additional TCP connections are made alongside the original connection, and the firewall needs to know to allow these through. The inspection engines perform simple analysis of traffic to watch for and set up these so-called <em>pinhole<\/em> ports, on demand.<\/p>\n<p>Trouble is, some of the inspection engines have suffered feature creep and now try to work out, I guess, the semantics of the exchange taking place. If the engine thinks the conversation contains &#8220;illegal&#8221; requests, it&#8217;s blocked.<\/p>\n<p>In particular the SMTP inspection engine (also known as a <em>fixup<\/em> in the Cisco docs) is fairly notorious for messing about with email transfer and preventing successful delivery. At best you might experience mysteriously missing attachments, at worst the remote server simply sees a TCP connection reset and has no idea why delivery failed.<\/p>\n<p>Here&#8217;s how to tell if your Cisco firewall is interfering with your mail server&#8217;s operation. Telnet to the mail server (we assume the firewall sits in front of it) on the standard port of 25, and look at the &#8220;banner&#8221; response. On a regular mail server the banner looks something like this:<\/p>\n<pre class=\"brush: plain; light: true; title: ; notranslate\" title=\"\">\r\nhost:~$ telnet oxmail.ox.ac.uk 25\r\nTrying 129.67.1.161...\r\nConnected to oxmail.ox.ac.uk.\r\nEscape character is '^]'.\r\n220 relay0.mail.ox.ac.uk ESMTP Exim 4.69 Thu, 26 Nov 2009 19:28:51 +0000\r\n<\/pre>\n<p>However on an affected server, the banner is noticeably different:<\/p>\n<pre class=\"brush: plain; light: true; title: ; notranslate\" title=\"\">\r\nhost:~$ telnet suspectserver.example.com 25\r\nTrying 192.0.2.1...\r\nConnected to suspectserver.example.com.\r\nEscape character is '^]'.\r\n220 *****************************************************************************\r\n<\/pre>\n<p>Disabling the SMTP fixup (which is on by default, I believe) enables mail to flow as it should. I recommend you do this on any PIX or ASA devices in your network.<\/p>\n<p>Note that the fixup seems to interfere with email going through the firewall in both directions, and problems occur regardless of the mail server software being used in the communication (after all, all servers are speaking the same SMTP protocol language).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This issue is old and familiar to us, and crops up about once every six months or so. I thought it might help to document the situation more publicly. On Cisco firewalls (PIX or the newer ASA), various protocol inspection &hellip; <a href=\"https:\/\/blogs-new.it.ox.ac.uk\/networks\/2009\/11\/26\/cisco-firewall-smtp-fixup-considered-harmful\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,123,9,124],"tags":[],"class_list":["post-190","post","type-post","status-publish","format-standard","hentry","category-cisco-networks","category-firewall","category-mail-relay","category-message-submission"],"_links":{"self":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts\/190","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/comments?post=190"}],"version-history":[{"count":9,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts\/190\/revisions"}],"predecessor-version":[{"id":2263,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/posts\/190\/revisions\/2263"}],"wp:attachment":[{"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/media?parent=190"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/categories?post=190"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs-new.it.ox.ac.uk\/networks\/wp-json\/wp\/v2\/tags?post=190"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}