Solved

Connected to <ip address> but connection died. (#4.4.2)

Posted on 2011-03-17
13
3,462 Views
Last Modified: 2012-05-11
Hi,

My client has an SBS 2003 Server running Exch 03 SP2.
Recently emails haven't been getting through to my client and its getting to become a very critical problem.
We have been lucky enough to get a bounceback message from one of their clients, which is below.
The setup is as follows:
Domain name is with Messagelabs (in the cloud anti virus filter) and the MX record points ot the public IP address of the mail server.
There is no pattern to the types of emails not getting through.
The ISP have confirmed its nothing to do with them.
Messagelabs have said from the smtp logs that its the mail server itself not them, an extract of the log is also below.
Please help.
Thanks

Extract 1: Bounce back from the original sender:
From: MAILER-DAEMON@messagelabs.com
Date: 16 Mar 2011 17:13:27
To: <abc@btopenworld.com>
Subject: Expired Delivery Retry Notification (7 days ): RE: subject of email : P00449-0070 This is the mail delivery agent at messagelabs.com.
I was not able to deliver your message to the following addresses.

<user@myclient.co.uk>:
Connected to 62.49.xx.xxx but connection died. (#4.4.2)

Despite repeated attempts, this message could not be delivered.

Extract 2: SMTP logs from Messagelabs

Delivery Results - Tower 195, Server 10
2011-03-16 19:33:50.693312500    new msg 624099
2011-03-16 19:33:50.693314500    info msg 624099: bytes 88244 from <abc@btopenworld.com> qp 12486 uid 1001
2011-03-16 19:33:50.693332500    ref msg 624099: server-10.tower-195.messagelabs.com!1300304029!53607840!1
2011-03-16 19:33:50.693594500    starting delivery 159927: msg 624099 to remote user@myclient.co.uk
2011-03-16 19:37:51.226223500    delivery 159927: deferral: Connected_to_62.49.xx.xxx_but_connection_died._(#4.4.2)/|
2011-03-16 19:40:30.103537500    starting delivery 160512: msg 624099 to remote user@myclient.co.uk
2011-03-16 19:44:30.609477500    delivery 160512: deferral: Connected_to_62.49.xx.xxx_but_connection_died._(#4.4.2)/|
2011-03-16 20:00:30.063374500    starting delivery 161892: msg 624099 to remote user@myclient.co.uk
2011-03-16 20:04:30.609103500    delivery 161892: deferral: Connected_to_62.49.xx.xxx_but_connection_died._(#4.4.2)/|
2011-03-16 20:33:51.137333500    starting delivery 164801: msg 624099 to remote user@myclient.co.uk
2011-03-16 20:37:51.695206500    delivery 164801: deferral: Connected_to_62.49.xx.xxx_but_connection_died._(#4.4.2)/|

Delivery of this message was deferred. Click here to search for further delivery attempts
2011-03-16 20:33:51.137333500    starting delivery 164801: msg 624099 to remote user@myclient.co.uk
2011-03-16 20:37:51.695206500    delivery 164801: deferral: Connected_to_62.49.xx.xxx_but_connection_died._(#4.4.2)/|
2011-03-16 21:20:30.132933500    starting delivery 167786: msg 624099 to remote user@myclient.co.uk
2011-03-16 21:24:30.747655500    delivery 167786: deferral: Connected_to_62.49.xx.xxx_but_connection_died._(#4.4.2)/|
2011-03-16 22:20:30.104230500    starting delivery 172680: msg 624099 to remote user@myclient.co.uk
2011-03-16 22:24:30.666627500    delivery 172680: deferral: Connected_to_62.49.xx.xxx_but_connection_died._(#4.4.2)/

0
Comment
Question by:teknite
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 8
  • 5
13 Comments
 
LVL 3

Expert Comment

by:bluebook
ID: 35161570
Do you have any corresponding logs on the SBS, maybe using the timestamps from the MessageLabs logs to cross reference?  (Their timestamps are GMT).

Also, when you say "the MX record points ot the public IP address of the mail server", you mean the MX record for your client's domain?  And pointing to the IP of the SBS, or to MessageLabs?  Finally, can you confirm that the IP address in the MessageLabs logs exactly matches the public IP of the SBS?

Actually one more thought: is there any kind of firewall in front of it (eg pics, or even ISA)?
0
 

Author Comment

by:teknite
ID: 35161628
Hi,
Thanks for the post, i dont, but we have just enabled Logging settings on the exchange server for the MSexchange Transport.
I can confirm the IP address in the message lab logs are the same as the public ip of the sbs server.
The MX record for my clients domain name points ot the public ip address.

Nothing on the sbs box itself, we do have a netgear router/firewall.
Thanks
0
 

Author Comment

by:teknite
ID: 35161661
domain name points to messagelabs then messge labs sends to public ip of sbs just for clarification.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
LVL 3

Expert Comment

by:bluebook
ID: 35164078
Will be interesting to see the exchange logs when you have them, but meanwhile here is what I was thinking regarding the firewall question: some firewalls, and pics is one of them, act as an smtp proxy.  That means that it is the firewall itself, and not the exchange server, which terminates the incoming smtp connection (from MessageLabs in this case).  So step 1 is MessageLabs connects to the firewall, and that gives you the "connected to <ip address>" part of the log message.  The firewall then attempts to connect to the exchange server, after which it will proxy the exchange server's SMTP greeting back to the connecting client.  However if for some reason it can't connect to the exchange server, then all it can do is drop the connection it accepted from the client - hence the "but connection died" part of the log message.


Another permutation of essentially the same problem is when the firewall is proxying at the TCP level, which is essentially what happens if you are using NAT, with a DMZ host or similar concept configured.  I.e. the SBS does not actually have a public address, but instead the firewall accepts the connection on the public address and then forwards it to a configured internal address.  Depending on the implementation it may accept the connection before or after establishing its own connection to the internal address; if it accepts it before, and then can't create the internal connection, again you will see connection dropped.  Does the SBS have an interface with the 62.49.xx.xxx address in the logs, or is that address forwarded to it by the firewall?

Without knowing more about your Netgear router I couldn't say whether either of these cases might apply, but in either case the question would be why the firewall is not able to connect to the exchange server.  You will probably need to see the logs to establish that (if indeed it is the case), but one possibility in the NAT case would be that the internal IP address of the SBS has changed since the firewall was configured.  If it's a static address that would be unlikely, but if for any reason it was dynamic then it could happen.
0
 

Author Comment

by:teknite
ID: 35194782
Here is the exchange log when 1 user sent an email. both internal users didn't get it, a non local address received it successfully.

We are using NAT, the firewall is accepting the connection on the public address and forwarding it onto the SBS box.
If you went ot the IP address you would get the SBS RWW component.
The internal IP hasn't changed for over 10 years and the IP is static.
Thanks

2011-3-18 9:9:47 GMT      0      -      c=US;a= ;p=LS;l=SERVER-110318090947Z-14069      -      EX:/O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=USER      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      abc@btopenworld.com      1027      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      c=US;a= ;p=LS;l=SERVER-110318090947Z-14069      -      EX:/O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=USER      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      /O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=User1      1019      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      -      -      -      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      thirdparty@domain.com      1019      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      -      -      -      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      abc@btopenworld.com      1019      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      -      -      -      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      /O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=User1      1025      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      -      -      -      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      thirdparty@domain.com      1025      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      -      -      -      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      abc@btopenworld.com      1025      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      -      -      -      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      /O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=User1      1024      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      -      -      -      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      thirdparty@domain.com      1024      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      -      -      -      -
2011-3-18      9:9:47 GMT      -      -      -      SERVER      -      abc@btopenworld.com      1024      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      3      2011-3-18 9:9:47 GMT      0      -      -      -      -      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      user1@myclient.co.uk      1033      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      1      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      user1@myclient.co.uk      1036      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      1      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      user1@myclient.co.uk      1023      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      1      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      thirdparty@domain.com      1033      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      2      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      abc@btopenworld.com      1033      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      2      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      user1@myclient.co.uk      1028      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      1      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      thirdparty@domain.com      1034      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      2      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      abc@btopenworld.com      1034      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      2      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      thirdparty@domain.com      1020      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      2      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      -      SERVER      -      abc@btopenworld.com      1020      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      08058      2      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      anchor-post-2.mail.demon.net      SERVER      -      thirdparty@domain.com      1031      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      2      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:9:48 GMT      -      -      anchor-post-2.mail.demon.net      SERVER      -      abc@btopenworld.com      1031      F3DC1AA3C654474FA487870136B68E9501609DC6@server.domain.local      0      0      8058      2      2011-3-18 9:9:47 GMT      0      -      -      -      user@myclient.co.uk      -
2011-3-18      9:10:17 GMT      85.158.138.147      mail195.messagelabs.com      -
0
 
LVL 3

Expert Comment

by:bluebook
ID: 35197611
I can't reconcile the log with your description of it.  Maybe I'm being stupid or maybe it's the formatting.  Can you post the header line from the log (the one with the list of field names in it)?

As I read this log, there appears to be a message created on your exchange server by user@myclient.co.uk, addressed to user1@myclient.co.uk, thirdparty@domain.com, and abc@btopenworld.com - is that right?  But above you said that "both internal users didn't get it, a non local address received it successfully."  I'm only seeing one internal user, and I'm seeing two non-local (external), so something doesn't tally.

It also appears that you have your smarthost set to anchor-post-2.mail.demon.net, rather than MessageLabs - is that right?  It's probably not relevant to your problem, but I wonder why that is?

Finally, assuming I haven't completely mis-intepreted this, your original question was about a problem where MessageLabs was connecting to your client and then losing the connection, whereas this log appears to be for a message which should be going the other way -i.e. a message originating on your client's exchange server and going out (although there is a partial entry right at the end of the log which shows MessageLabs as a client).

To understand the original "connection died" problem, the SMTP log is going to be more useful than the message tracker log.  If you can get the corresponding log from MessageLabs to compare with, so we can see both sides of the connection, that will help considerably.

0
 

Author Comment

by:teknite
ID: 35202934
Hi,
Just to clarify
abc@btopenworld.com is the sender.
user@myclient.co.uk is the intended recipient who doesn't get the email
user1@myclient.co.uk is a 2nd recipient who also didn'tget the mail
3rdparty@domain.com is me

abc@ sent the email to user, user1 and 3rdparty
our ISP is Demon, hence the smarthost
Meesagelabs scans our emails before being delivered to the mail server.

i'll speak to messagelabs to get the logfile.
Thanks
0
 
LVL 3

Expert Comment

by:bluebook
ID: 35203439
If you can get your smtp log as well that will definitely help.

Still can't get my head round that tracker log.  If this mail was sent from outside the exchange server, then thirdparty@domain.com shouldn't appear in the log at all.  Nor, for that matter, should your demon smarthost, because this should be message from outside coming in (via messagelabs), whereas the log shows a message from the inside going out (via demon).

MessageLabs usually act as smarthost for their customers, in addition to scanning their inbound mail, especially if you have the anti-virus service.  That way your outbound mail gets acanned as well, which is good for protecting your reputation - but it's not essential.
0
 

Author Comment

by:teknite
ID: 35203476
So, in your opinion without confirming the logs, this is someone inside sending to all recipients rather than our btopenworld client sending message to us?

If thats the case, then exchange is def not seeing the email coming in at all yet messagelabs say its a problem on the server itself, which i still can't see how, when all other mail works fine.
0
 
LVL 3

Expert Comment

by:bluebook
ID: 35210313
Yes, that's my opinion, although I'm not sure what the last line of the log (which mentions MessageLabs) is about.  That line looks as if it is truncated, but also there's a 20 second gap between it and the previous entry, which makes me think the 2 are not related.

When you say all other mail works fine, you mean internal mail and outgoing mail?  Or do you have other mail coming in from outside which works?  If it's just internal and outgoing which is working that again suggests there's an issue in either the firewall or the smtp server.  Have you tried connecting directly from outside using telnet to port 25?  If you have configured your firewall to only accept connections from MessageLabs then you won't be able to do that, but otherwise you should get an SMTP banner from your exchange server, and you should then be able to send in a message by typing SMTP commands directly.
0
 

Author Comment

by:teknite
ID: 35210967
Both internal and external mail is fine apart from a handful of domain names.
Interestingly enough after messagelabs told me categorically thats its the exhange server, one decent knowledgeable guy indicated the problem could be that exchange needs to know all the ip's that mail could come from and that this could be the problem that maybe a single or small cluster of messagelabs servers are at fault.

they are sending over to me all the trusted ip's for their servers and see whether this helps get the mail in.

I will keep you posted and so far thanks for all you help, as this is driving me crazy!
0
 

Accepted Solution

by:
teknite earned 0 total points
ID: 35388075
I was advised certain messagelab servers weren't making a connection to the server, they issued a list of trusted IP's and this didn't make a difference, in fact things got worse.

We have decided to remove messagelabs out of the equation and so far things have been working well.
Thanks bluebook for all your help, greatly appreciated.
0
 

Author Closing Comment

by:teknite
ID: 36400570
self resolved.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Scam emails are a huge burden for many businesses. Spotting one is not always easy. Follow our tips to identify if an email you receive is a scam.
Find out what you should include to make the best professional email signature for your organization.
In this video we show how to create an Accepted Domain in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Ac…
To add imagery to an HTML email signature, you have two options available to you. You can either add a logo/image by embedding it directly into the signature or hosting it externally and linking to it. The vast majority of email clients display l…

733 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question