Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 24 replies
  • Subscribers 1 subscriber
  • Views 12055 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
    See what happens if you add a packet filter rule to open port 465: 'Internal (Network) -> SMTP SSL -> Any : Allow'.
     
    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
    Do you have IPS enabled?

    the upstream hosts of our provider are in the upstream host list as hosts (ip address), upstream hosts only option is checked


    Try unchecking that option. Also when I use upstream host option, I try to use the fqdn in definitions that way if they have more than one IP, you don't run into problems.
  • 0 in reply to Billybob
    Hi Folks,

    when I took a closer look at the smtp.log, I saw that very few TLS-encrypted mails are going through. But for the majority of the TLS-encrypted mails, our provider gets an connection reset and also sees the following error message in his maillog: sendmail[1596]: STARTTLS=client, relay=xyz.mydomain.com, version=TLSv1/SSLv3, verify=FAIL, cipher=DES-CBC3-SHA, bits=168/168. IPS ist not enabled, the upstream hosts are defined by ip addresses instead of hostnames because our provider has two single hosts but each host has about three or four aliases. I also tried unchecking the upstream hosts only option, no success.

    Torsten
  • 0 in reply to RAG220
    And you already had port 465 open?
     
    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 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
  • 0 in reply to RAG220
    I just checked our Astaro as well as ASGs at two customer sites to confirm; all three sites are on Exchange 2003 and use Verify Recipient with callout.  I've played with it with AD, and did have some problems.

    If Astaro Support left it set to Verify Recipient with callout, they did the right thing.

    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,

    Astaro Support set the recipient verification to off, that is my problem. [:S] In the Mail Manager, I see a lot of mails with status 'bounced', but our provider told me that he doesn't get any bounces, so I don't know where these bounces go. I have set the mailserver of our provider as outgoing smarthost, so he should recognize any bounces. Anyway, I'm glad that I can use the V7 SMTP proxy, because the spamfilter is far superior than the old one used in V6.

    Torsten
  • 0 in reply to RAG220
    The "Bounced" emails are ones returned to you, so your provider wouldn't see them.  The provider might be able to see the emails "Rejected" by your Astaro.

    If you had 'Verify Recipient' set to "in Active Directory", then I'd replace that with "with callout" and see if things work correctly.  If you already had "with callout", then reopen a ticket with Astaro as there is no problem I know of.  If they want to tell you otherwise, then please ask for specifics and post them here.

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

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

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

Cookie Information Banner