ASA 5505 - Incoming Email, Inspection Problem?


Hello Everyone,
I have to break out the experts on this one. I took on a new client which I ended up going through a server upgrade from SBS2003 to SBS2008 (New Servers), the install went fine and everything was working well for the first 2 weeks or so. They contacted me b/c they happened to notice that after a few days they were not getting new emails coming in from a particular sender, they just seemed to suddenly stop. So first thing first I check the Exchange Transport logs to rule out any spam issues and defiantly ruled out that it wasn’t a spam issue.
After going through the motions I had the sending administrator check his logs to make sure that the emails were going out and even have them carbon copy me. What we found was that I was getting the messages and my client wasn’t.  After looking at the server logs I determined that the messages weren’t ever even hitting the server.
Next step was to look at the Firewall which an ASA 5505 running 7.2.2. After looking at the logs I came across this and I am pulling my hair out trying to figure out what the next step in resolving this would be. Below is a copy of the log:

216.xxx.xxx.xxx –= Sending mail server
216.yyy.yyy.yyy  = Outside interface on ASA, they only have one static external and using NAT


*****************

6|Sep 15 2010|15:52:21|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/56248 to 216.yyy.yyy.yyy/25 flags ACK  on interface outside
6|Sep 15 2010|15:52:21|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/56248 to 216.yyy.yyy.yyy/25 flags ACK  on interface outside
6|Sep 15 2010|15:52:21|302014|216.xxx.xxx.xxx|192.168.123.10|Teardown TCP connection 1720395 for outside:216.xxx.xxx.xxx/56248 to inside:192.168.123.10/25 duration 0:10:00 bytes 21771385 TCP Reset-I
6|Sep 15 2010|15:52:20|302016|216.178.92.98|192.168.123.10|Teardown UDP connection 1720681 for outside:216.178.92.98/53 to inside:192.168.123.10/61481 duration 0:00:02 bytes 197
6|Sep 15 2010|15:52:19|302014|82.127.95.245|192.168.123.10|Teardown TCP connection 1720674 for outside:82.127.95.245/53308 to inside:192.168.123.10/25 duration 0:00:05 bytes 485 TCP FINs
6|Sep 15 2010|15:52:17|302016|216.178.92.98|192.168.123.10|Teardown UDP connection 1720682 for outside:216.178.92.98/53 to inside:192.168.123.10/54136 duration 0:00:00 bytes 189
6|Sep 15 2010|15:52:17|302015|216.178.92.98|192.168.123.10|Built outbound UDP connection 1720682 for outside:216.178.92.98/53 (216.178.92.98/53) to inside:192.168.123.10/54136 (216.yyy.yyy.yyy/16517)
6|Sep 15 2010|15:52:17|305011|192.168.123.10|216.yyy.yyy.yyy|Built dynamic UDP translation from inside:192.168.123.10/54136 to outside:216.yyy.yyy.yyy/16517
6|Sep 15 2010|15:52:17|302015|216.178.92.98|192.168.123.10|Built outbound UDP connection 1720681 for outside:216.178.92.98/53 (216.178.92.98/53) to inside:192.168.123.10/61481 (216.yyy.yyy.yyy/16516)
6|Sep 15 2010|15:52:17|305011|192.168.123.10|216.yyy.yyy.yyy|Built dynamic UDP translation from inside:192.168.123.10/61481 to outside:216.yyy.yyy.yyy/16516
6|Sep 15 2010|15:52:16|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/56166 to 216.yyy.yyy.yyy/25 flags ACK  on interface outside
6|Sep 15 2010|15:52:16|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/56166 to 216.yyy.yyy.yyy/25 flags PSH ACK  on interface outside
6|Sep 15 2010|15:52:16|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/56166 to 216.yyy.yyy.yyy/25 flags ACK  on interface outside
6|Sep 15 2010|15:52:16|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/56166 to 216.yyy.yyy.yyy/25 flags ACK  on interface outside
6|Sep 15 2010|15:52:16|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/56166 to 216.yyy.yyy.yyy/25 flags ACK  on interface outside
6|Sep 15 2010|15:52:16|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/56166 to 216.yyy.yyy.yyy/25 flags ACK  on interface outside
6|Sep 15 2010|15:52:16|302014|216.xxx.xxx.xxx|192.168.123.10|Teardown TCP connection 1720394 for outside:216.xxx.xxx.xxx/56166 to inside:192.168.123.10/25 duration 0:10:01 bytes 22238610 TCP Reset-I

*************

You can clearly seeing the connection being dropped but the problem is why, nothing has changed on the ASA and I will be honest this is not my strong point. Please guide me in the right direction…

Thank you,
-Mike
LVL 5
BAYCCSAsked:
Who is Participating?
 
BAYCCSConnect With a Mentor Author Commented:
very very true we all have those moments!

Thanks again!
0
 
BAYCCSAuthor Commented:
I should also mention 192.168.123.10 is the Internal IP of the server.
0
 
AngloConnect With a Mentor Commented:
Have you tried the packet tracer tool in ASDM?
0
Get Cisco Certified in IT Security

There’s a high demand for IT security experts and network administrators who can safeguard the data that individuals, corporations, and governments rely on every day. Pursue your B.S. in Network Operations and Security and gain the credentials you need for this high-growth field.

 
BAYCCSAuthor Commented:
No, I will try that now and post back
0
 
dazm_2000Connect With a Mentor Commented:
Have you tried removing the esmtp inspect off?.

conf t
policy-map global_policy
 class inspection_default
no inspect esmtp
end

wri mem
0
 
BAYCCSAuthor Commented:
Test's good.
packetcap.jpg
0
 
BAYCCSAuthor Commented:
I read some other post and actually I knew about the no fixup protocol smtp. Let me check on that and get back to you.
0
 
BAYCCSAuthor Commented:
I double checked and it isn't inspecting emstp.

******************


class-map type regex match-any websiteList
 match regex domainlist1
 match regex domainlist2
 match regex domainlist3
 match regex domainlist4
 match regex domainlist5
 match regex domainlist7
 match regex domainlist6
class-map inspection_default
 match default-inspection-traffic
class-map type inspect http match-all websiteClass
 match request header host regex class websiteList
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
policy-map type inspect http http_website_policy
 parameters
 class websiteClass
  reset log
policy-map global_policy
 description RDP
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect http http_website_policy
!
service-policy global_policy global
0
 
BAYCCSAuthor Commented:
I just had the sender try and send the emails again and they still didn't come though, I should also point put that these emails do seem to have attachments on them, a couple PDF and XLS totaling about 3MB. I know the size isn't the issue b/c I have already checked.
0
 
BAYCCSAuthor Commented:
OK I have stumbled onto something interesting. I had the sender send out the emails this time one that had some PDFs and one Excel file and a message with only the PDFs, can you guess which one worked?

The one with only the PDF's worked.

Either this is just freaky coincidence or the ASA for some reason doesn't like the Excel file. Is there anything I can turn off too test this?
0
 
DonbooConnect With a Mentor Commented:
If the ASA isnt doing inspection on SMTP/ESMTP and you still have problems with attachments its most likely not the ASA but the server. However and upgrade to version 8.2 would be a bad idea.
0
 
BAYCCSAuthor Commented:
an upgraded would or wouldn't be bad idea? that was my next plan.
0
 
Markus BraunConnect With a Mentor CEOCommented:
Hi, i have a few running on the latest 8x version, but honestly, unless there is something you require in the 8x , dont upgrade
but you should go for the lastest 7x since 722 is old
in the newest 8x alot of things changed - especially NAT configration - and that can be confusing - no to recommended on live machines.
Also it has a higher memory requirement with some configs.

So if you are still on 722 go to the lastest 7x which is a GD deployment and it works very good.

Back to your problem... if the inspect is off, it will not be inspected - period.
Problems like that i have seen with wrong nat configs or sometimes ICMP unreachables beeing blocked somewhere on the way
if that all checks out ok, it would be interesting to know what email server they use, maybe there are some known issues which can be found i am sure - with google....
0
 
DonbooCommented:
Wouldnt be a bad idea i meant to say.
0
 
AngloConnect With a Mentor Commented:
sounds like it may be spam filter settings if the pdf gets through ok
0
 
sudeep_mibCommented:
Are you using any CSC module or any IPS module on ASA. It could be possible that CSC module or IPS module could be blocking the emails
0
 
BAYCCSAuthor Commented:
Ok here is an update. I went onsite last night and upgraded the ASA from 7.2.2 to the latest GD release which was 7.2.5. I then actually erased the entire config and rebuilt the unit from scratch b/c I didn't like how their previous IT guy set it up.

On my way home I received in my inbox a copy of the mail that they two should have also gotten, the email contained the Excel file and a few PDFs. So when I got home I logged into the server and also the ASA and I looked in the Exchange message tracking and noticed that the message never came through, I also noticed that the connection was very slow, they are using a T1 pipe and at that hour nothing should be going on.

I logged into the ASA and I see my favorite line running in the log:
6|Sep 16 2010|23:28:59|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/52726 to 216.yyy.yyy.yyy/25 flags ACK on interface outside
6|Sep 16 2010|23:28:59|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/52726 to 216.yyy.yyy.yyy/25 flags ACK on interface outside
6|Sep 16 2010|23:28:59|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/52726 to 216.yyy.yyy.yyy/25 flags ACK on interface outside
6|Sep 16 2010|23:28:59|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/52726 to 216.yyy.yyy.yyy/25 flags ACK on interface outside
6|Sep 16 2010|23:28:59|106015|216.xxx.xxx.xxx|216.yyy.yyy.yyy|Deny TCP (no connection) from 216.xxx.xxx.xxx/52726 to 216.yyy.yyy.yyy/25 flags ACK on interface outside

Now keep in mind the connection is pegged at almost 1450 Kbps for a good 5 mintutes or so drops back down and maybe within 10 minutes pegs out again. It almost seems like the sending mail server is trying to keep sending the message due to the dropped TCP connection.

So obviously it’s late and give up for the night and this morning I forward the email sitting in my box to my client and in less than 5 minutes I got an email back from them telling me that they got the email at 4:02AM this morning. So now that tells me the sending server kept trying and trying and eventually got through.

I am really stumped at this point and don’t even know where to look next. I really believe this to be an issue with the sending server but this is a big company that sends out emails to franchises all over the county and claim that they have checked their logs and the mail leave their system.

0
 
Markus BraunConnect With a Mentor CEOCommented:
I am with you on that one. But to get to the bottom of this, the email sender admin would have to work with you to figure it out and do some testing. Questionable if they do that.
On the other hand, there are lots of firewalls out there that are not "as picky" as the ASA and stuff like that may just slip through. There is a lot of possibilities of what and why it happend.
Is this happening with every email? or just the ones with excel files ??
it may help if you set up a sniffer on the WAN side (filter that source ip of course) and have them send that again so you actually see what is happening before it its the ASA.
Of course it will take a while to go through the sniffers recording and find out what actually is happening but it will tell you alot more than just the firewall logs
0
 
BAYCCSAuthor Commented:
Yea I think that may be my next step to put an inline TAP between the T1 line and ASA and capture the packets using wireshark and see what the heck it going on.
0
 
BAYCCSAuthor Commented:
Hello Everyone,

First I just want to thank everyone for helping me with this issue and I feel really stupid now that I know what was causing it…
On Friday I turned on some Verbose SMTP Receive Connector logs in Exchange 2007 and waited for the sending mail server to send a mail. Finally this morning they send a message to my server and this server and after looking in the logs you can see the initial communication you can clearly see that the incoming server is accepting in the mail with a 354 Start mail input.
Well little would you know 10 minutes later in the log I got the message 421 4.4.1 Connection timed out.
All I had to do to fix the issue was up the timeout on the Internet Facing SMTP Connector from 10 minutes to 30 using the command:
Set-ReceiveConnector "NAME OF CONNECTOR" -ConnectionTimeout 00:30:00
Where NAME OF CONNECTOR is the name of the connector
0
 
Markus BraunCEOCommented:
Glad you found it, i remember when i forgot a nat statement and was wondering why i cant pass traffic, so i have my stupid moments too, and that after 2500 configured firewalls , lol  :)

Most importantly , IT WORKS NOW:)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.