Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 24 replies
  • Subscribers 1 subscriber
  • Views 12034 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Connection reset by Astaro

RAG220
Hi Folks,

we have just upgraded our Astaro ASG220 to V7.401 at the weekend (fresh install on a new delivered appliance). Now we are having problems with incoming mail. For some reason, the upstream mailserver of our provider gets an "connection reset" from the astaro. There are incoming mails anyway, but since saturday when i switched the new installation online the queue on our provider's server has been built up to over 4.000 mails that can not be transmitted. I am using the Astaro's SMTP proxy in simple mode with static routing to a single Exchange 2003 server with callout, antivirus with single engine, antivirus and antispam during SMTP transaction off, no rbl, no blocking of dialup hosts, no sender blacklist, no greylisting, no BATV, no SPF, no missing RDNS. No exceptions, the upstream hosts of our provider are in the upstream host list as hosts (ip address), upstream hosts only option is checked. Host based relay for the Exchange server, no host blacklist, scanning of outgoing messages off. The proxy is not in transparent mode. I got a copy of the provider's sendmail logfiles, at the time when a connection reset is logged, the smtp log of the astaro didn't log any event at all. When I loook over the smtp.log, I can see that there is never more than one simultanious connection, so there is not an issue with too many concurrent connections. At all, I don't know why the astaro is doing a connection reset. When I switch back to our old V6.314 appliance, the mails start coming in. Has anyone an idea where to look why the V7.401 appliance is resetting incoming connections from our provider?

Thanks, 

Torsten


This thread was automatically locked due to age.
Parents
  • 0
    Do you have a spelling error in your domain name on the 'Routing' tab?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Hi Bob,

    no error in the domain names on the routing tab. It seems that TLS is causing this fault. If the upstream host tries to submit a TLS-encrypted mail, it gets an connection reset. Outgoing encryption is disabled, TLS settings on the 'advanced' tab are not configured. The old V6 appliance doesn't have these problems, once I put the old box online, the mail flows.

    Torsten
  • 0 in reply to RAG220
    Hi Folks,

    just a little update. My retailer opened up a call with Astaro. They dialed up on my box and told me that recipient verification is causing the problem. When it is switched off, the mails are received flawlessly. Unfortunately, Astaro closed the call without further investigation and refuses to go into detail. They just told me "V7 recipient verification doesn't work with your Exchange 2003, we don't know why, and as mails are received without recipient verification, we close the call right here". Very frustrating behaviour of Astaro. Is anybody else experiencing problems with recipient verification and Exchange 2003?

    Torsten


    Are you sure they didn't say (or mean) Exchange Server 2007?  Receipient callout works fine on all the Exchange 2003 installations we support, but Receipient Callout does fail when used with an Exchange Server 2007 installation unless you make a change to Exchange 2007 (this is an Exchange Issue, not an Astaro issue).  See http://portal.knowledgebase.net/article.asp?article=247822&p=5956 ..

    If you are running Exchange 2003, do you have any add-on programs (anti-spam software, etc.) that may be creating a "tarpit" that is causing the issues on your Server?  It also looks like the tarpit "feature" is available on Exchange 2003, but is turned off by default... maybe check the Microsoft KB and see if you can make sure it is turned off (maybe someone turned it on) on your server.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    Hello there,

    I configured the Recipient Verification originally as 'with callout', and with this setting I had the problem that almost every mail that was not spam and was sent to an existing recipient was rejected by the Astaro with a connection reset. There were no logfile entries except the ones on our provider's mailserver that would proof this connection reset. I did never try the Recipient Verification in Active Directory. Greylisting was never activated, also. The weird thing is that spam mails for non-existing recipients were correctly rejected with a 550 answer and were also logged in the Mail Manager as rejected by Recipient Verification. Also, spam mails for existing recipients were classified as spam and tagged and delivered (spam) respectively quarantined (confirmed spam), according to my settings.

    We have an Exchange Server 2003, tarpitting is definitely not activated. We have a Trend Micro ScanMail for Exchange 8.0 installation on this Server, which has also an anti-spam feature included. As for now, this anti-spam is activated because the anti-spam feature of the Astaro V6 was not very effective. The one thing that confuses me is the fact, that on our old V6 Astaro the Recipient Verification is also activated and with the V6 we never had such problems. Even if I replace the V7 with the V6 today, the V6 with active Recipient Verification works absolutely flawless.

    Torsten
  • 0 in reply to RAG220
    There is something definitely unique about your 2003 installation; I would start by disabling the Trend Micro software (temporarily) with the Astaro in front of it... most (but not all) of my customers that are using the Email Security features of the Astaro are using it with Exchange 2003.  I have one customer that does use it with Exchange 2007, and the only problem we encountered was the "tarpit" setting that comes set on by default on Exchange 2007 ... we turned that off and all was well.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to RAG220
    Unfortunately, Astaro closed the call without further investigation and refuses to go into detail. They just told me "V7 recipient verification doesn't work with your Exchange 2003, we don't know why, and as mails are received without recipient verification, we close the call right here". Very frustrating behaviour of Astaro.

    Shame on you, Astaro...

    My Idea would be to trace the Traffic between the ASG and Exchange while recipient verification is on, maybe we see something there...
  • 0 in reply to SveN_01
    Hi SveN,

    I did trace the traffic between the Astaro and the Exchange with Recipient Verification activated and - bingo! I found a case where the astaro did a callout for an existing address, the Exchange answers with 250 (OK), the astaro answers with QUIT and then does an SMTP connection reset. In the logs of the astaro, there are no entries regarding this transaction. I sent my trace to Astaro Support, no reaction so far.

    Torsten
  • 0 in reply to RAG220
    Hi SveN,

    I did trace the traffic between the Astaro and the Exchange with Recipient Verification activated and - bingo! I found a case where the astaro did a callout for an existing address, the Exchange answers with 250 (OK), the astaro answers with QUIT and then does an SMTP connection reset. In the logs of the astaro, there are no entries regarding this transaction. I sent my trace to Astaro Support, no reaction so far.

    Torsten

    Maybe you can post the trace, so we could compare?
    (My internal Mailserver is *not* Exchange, but maybe we see something)
  • 0 in reply to SveN_01
    Hi SveN,

    in the attached textfile you can see the relevant portion of the trace, ip- and mail-addresses anonymized.

    In the meantime, I temporarily deactivated all Trend Micro ScanMail for Exchange features, still connection resets to the provider with recipient verification with callout activated.

    Torsten
  • 0 in reply to RAG220
    Hhhhmm, the only difference is that after the RCPT TO: Command the (nearly) same response appears but in you case Astaro says "QUIT" and in my case "DATA". 
    1	0.000000	192.168.100.1	192.168.100.209	TCP	46592 > smtp [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=277519834 TSER=0

    2	0.000070	192.168.100.209	192.168.100.1	TCP	smtp > 46592 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 TSV=0 TSER=0

    3	0.000221	192.168.100.1	192.168.100.209	TCP	46592 > smtp [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=277519834 TSER=0

    4	0.003314	192.168.100.209	192.168.100.1	SMTP	S: 220 Welcome to my Internal Mailserver

    5	0.003432	192.168.100.1	192.168.100.209	TCP	46592 > smtp [ACK] Seq=1 Ack=44 Win=5840 Len=0 TSV=277519835 TSER=13629240

    6	0.003572	192.168.100.1	192.168.100.209	SMTP	C: EHLO astaro.mydomain.com

    7	0.005360	192.168.100.209	192.168.100.1	SMTP	S: 250-Hello astaro.mydomain.com | 250-ENHANCEDSTATUSCODES | 250 SIZE 0

    8	0.005519	192.168.100.1	192.168.100.209	SMTP	C: MAIL FROM: SIZE=2585

    9	0.007407	192.168.100.209	192.168.100.1	SMTP	S: 250 2.1.0 extern@sender.com Address Okay

    10	0.007531	192.168.100.1	192.168.100.209	SMTP	C: RCPT TO:

    11	0.019737	192.168.100.209	192.168.100.1	SMTP	S: 250 2.1.5 valid.user@mydomain.com Address Okay

    12	0.019849	192.168.100.1	192.168.100.209	SMTP	C: DATA

    13	0.020685	192.168.100.209	192.168.100.1	SMTP	S: 354 Start mail input; end with .

    14	0.020960	192.168.100.1	192.168.100.209	SMTP	C: DATA fragment, 1448 bytes


    Does this happen to all of you recipiens or only to some?
    Could you create a trace for *invalid* user to see if the behaviour is the same as with valid user?
  • 0 in reply to SveN_01
    Hi SveN,

    that's exactly my problem. My mailserver says 'recipient OK', the Astaro says 'QUIT' instead of sending "DATA'. For invalid users, everything is fine, the mailserver says '550' and the Astaro rejects the mail. The rejection is also logged in the smtp.log and in the Mailmanager. Spam-mails for valid users are delivered without any problems (if I set the option to 'warn'). Only non-spam-mails for valid users are not delivered by the Astaro, in these cases the Astaro resets the connection after getting a '250' for the recipient. The worst thing ist that the Astaro does not show any logfile entries at all for these connection resets.

    Torsten
  • 0 in reply to RAG220
    Hey RAG220; check your IPS logs; I have seen cases (it's been a long time ago, though) where certain legitimate SMTP communications were detected by the IPS as an attack; I don't see those anymore, but I do have a standard list of IPS rule exceptions that I put on every system, and a couple of them are SMTP-oriented... I recall this happening with Exchange to Astaro (and vice versa) communications.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Reply
  • 0 in reply to RAG220
    Hey RAG220; check your IPS logs; I have seen cases (it's been a long time ago, though) where certain legitimate SMTP communications were detected by the IPS as an attack; I don't see those anymore, but I do have a standard list of IPS rule exceptions that I put on every system, and a couple of them are SMTP-oriented... I recall this happening with Exchange to Astaro (and vice versa) communications.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Children
Cookie Information Banner