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
    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.

  • 0 in reply to BrucekConvergent
    Hi Bruce,

    IPS is turned off. I turned it off on V6 due to performance issues and haven't it activated on V7 so far.
  • 0 in reply to RAG220
    Spam-mails for valid users are delivered without any problems (if I set the option to 'warn').

    Strange thing. I do not know if Astaro does a Recipient Verifiycation for SPAM Mails which are set to 'warn'. Normaly Astaro should!

    Do you think you could trace a Recipient Verifiycation for a Mail which has Spam Level 'warn'?

    But nevertheless, I think Astaro should have a look at this problem!
  • 0 in reply to SveN_01
    SveN, are you saying that you have V7.4 and Recipient Verification "with callout" is active, but it doesn't work if you have 'Spam Action' set to "Warn" in the SMTP Proxy?
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0 in reply to SveN_01
    SveN, are you saying that you have V7.4 and Recipient Verification "with callout" is active, but it doesn't work if you have 'Spam Action' set to "Warn" in the SMTP Proxy?
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 0 in reply to BAlfson
    SveN, are you saying that you have V7.4 and Recipient Verification "with callout" is active, but it doesn't work if you have 'Spam Action' set to "Warn" in the SMTP Proxy?

    No, of course not :-)

    But RAG220 said:
    "Spam-mails for valid users are delivered without any problems (if I set the option to 'warn')"
    ...so I suggested to trace such a maildelivery because in this case the recipient verifiycation seems to work....

    cu SveN
Cookie Information Banner