Solved

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

Posted on 2011-03-17
13
3,237 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
  • 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
 
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
Don't lose your head updating email signatures!

Do your end users still have the wrong email signature? Do email signature updates bore you or fill you with a sense of dread? You can make this a whole lot easier on yourself by trusting an Exclaimer email signature management solution. Over 50 million users do...so should you!

 

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

Don't lose your head updating email signatures!

Do your end users still have the wrong email signature? Do email signature updates bore you or fill you with a sense of dread? You can make this a whole lot easier on yourself by trusting an Exclaimer email signature management solution. Over 50 million users do...so should you!

Join & Write a Comment

We are happy to announce a brand new addition to our line of acclaimed email signature management products – CodeTwo Email Signatures for Office 365.
Resolve Outlook connectivity issues after moving mailbox to new Exchange 2016 server
Familiarize people with the process of utilizing SQL Server views from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Access…
In this video we show how to create a Resource Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: Navigate to the Recipients >> Resources tab.: "Recipients" is our default selection …

760 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

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now