Messaging Gateway

 View Only
  • 1.  Outgoing connection refused

    Posted Jan 12, 2023 01:36 PM
    The thread I started yesterday about DDS errors may be unrelated to the real problem.

    On our internal mail server postfix is logging:

    <recipient address>: connect to xxx.xxx.xxx.12[xxx.xxx.xxx.12]:25: Connection refused

    xxx.xxx.xxx.12:25 is the outbound interface of our SMG and as far as I can tell this is happening for every outgoing message now.
    There is nothing else in the mail server logs, obviously SMG is not providing a reason for refusing a connection.

    The mail server IP is listed under Configuration -> SMTP -> Outbound -> Outbound mail acceptance

    Our LAN is listed under Configuration -> SMTP -> Internal mail hosts
    The mail server was not listed under internal mail hosts because it is on the LAN, but I added it just to be sure, and it has made no difference.

    To clarify, we have sent outgoing mail since the SMG update to 10.8, and since the mail server was updated to Debian 11.6.
    The postix queue has deferred messages from the 10th Jan, although I see that my boss was able to send 2 messages on the 11th, although these may have been just prior to installing the SMG patch - I don't thnk any email has been sent out from the internal mai s erver since then (although connecting directly the the SMG for SMTP Auth seems to work).

    Where can I find the SMTP logs on SMG to see if there are any clues as to why it is refusing to accept an SMTP connection from our internal mail server?




  • 2.  RE: Outgoing connection refused

    Posted Jan 12, 2023 01:37 PM
    yuk




  • 3.  RE: Outgoing connection refused

    Posted Jan 18, 2023 10:43 AM
    I think I have finally got to the bottom of this, and the other problems I have been having.

    It was a smoke alarm all along!

    Explanation needed?  Of course.
    After going through some stuff with tech support they couldn't see that our mail server had actually tried to initiate connections in the diagnostic logs from SMG, so asked me to telnet SMG from the mail server. I had tried this already but being just a guy who also does IT, I specified the port wrong (: instead of space), and it was only when I tried without specifying the port at all earlier today that I got a response, from the RAID card on our main file server.

    So it was an IP conflict all along.

    But why?
    That RAID card used to have a different IP address and I hadn't made a note that it had been changed, but I didn't actually have it plugged into the LAN, so why was I now connecting to it?
    Then I remembered something.
    A few weeks ago (About the time I updated to 10.8) my boss called because there was a beeping from the server cabinet, obviously I couldn't diagnose it over the phone but he decided it was coming from the back of the file server. I mentioned that when the backup battery on the RAID card goes flat it beeps loudly in that area and got him to try to determine if that was it - he must have seen the card wasn't connected and patched it to the switch. He called back later that day to let me know he eventually found the beep, it was a smoke alarm flat battery warning, not even in the server cabinet.
    So is it my fault for having a piece of hardware set up with a duplicate IP address (and no record of it), or his fault for plugging it in to solve a smoke alarm battery issue - obviously I'm blaming him.

    With the RAID card set to the address I had written down (which I know doesn't clash with anything else), telnetting to port 25 on SMG gets me a proper SMTP helo response, the mailserver is now able to connect to it again and the postfix queue has cleared (although most had expired and failed permanently by then). I haven't seen any DDS errors since doing this (SMG uses that IP to connect to the LDAP (AD DC) server), and have queued up a backup for tonight to see if that will succeed.

    I will try to remember to update tomorrow to confirm if the scheduled task are working properly again, but everything looks promising right now.

    In the middle of running diagnostics I did also become concerned about the health of the VMware host machine which temporarily wasn't seeing its datastore, I'm wondering if that was a degraded RAID volume rebuilding at the same time. I need to check and replace the hot spare if it was, but so far today everything is running smoothly again.


  • 4.  RE: Outgoing connection refused

    Broadcom Employee
    Posted Jan 18, 2023 03:18 PM
    Too late for you, since you seem to have things under control, but perhaps for others who might view this thread, it (just this morning) occurred to me that a potentially useful diagnostic might have been the SMG reporting engine.   In your case, selecting a report type of "IP Connections" and then you could play around with the sub-type (Accepted, Rejected).  While it is difficult to "prove a negative",  in your case, the fact that your mail server didn't show up in the reports would be a tip/clue that something else was going on.

    I had a similar situation a while back (not related to SMG, but "someone" grabbed an IP address that was already in use).  I tracked them down using arp tables and a bit of port scanning to fingerprint the "offending" device and owner. ;)


  • 5.  RE: Outgoing connection refused

    Posted Jan 19, 2023 04:46 AM
    Yes, with the wealth of logs available on SMG I was surprised that I couldn't find one that let me see IP related events directly and required me to set up a tcpdump, replicate the issue and send the dump to support to have analysed.

    However, I can now confirm that scheduled backups are working for me alongside DDS and outgoing email, so I'm going to close the ticket.

    I doubt if my experiences are going to help any of the guys with long term issues but I like to wrap these threads up in case anyone with similar problems comes across them in the future.