Cannot email or telnet on port 25 to external mail server...

I have been struggling with a situation with connecting to an external mail server for years (!) now.  I have turned on all of the logging that I can think of with our Astaro 220 in an effort to nail down this problem, but I haven 't found anything yet.

I have tested DNS with a ping mail.problemdomain.com, and it resolves the IP address correctly.  The ping fails (as it probably should) and the response from the ping is "Reply from 192.168.1.1: Destination host unreachable."  The 192.168.1.1 is the address of our Astaro 220, which I assume is normal.

From my Astaro protected network, I cannot telnet on port 25 to mail.problemdomain.com and I get a "connect failed" message.  When I go to our backup internet connection, or from my home connection, I can telnet and connect to this domain.  

I have added a packet filter on my Astaro at the top of the list that allows my computer to send to this domain on any port, this domain in both directions on port 25, and various other packet filter defeating settings.  I have increased the logging in this area, and the requests on port 25 to this domain are shown as being allowed.

It looks like whenever the source is our public IP, or when the requests are being routed through our Astaro 220, this domain is like a black hole to me.  I have been in contact with the IT folks in control of this domain, and aside from having trouble with them responding, they have reviewed thier setup and do not see anything that could be causing the problem.  I had assumed that we had somehow become black listed, but I have tried an additional IP address on our DMZ on this same Astaro and it is also blocked.

This has led me to believe that either the Astaro is somehow blocking this and I can't find the right logs to see why, or the domain admins of the other domain are black listing us or have a configuration issue of some sort.

I am at a loss at how to proceed, and would welcome any suggestions for trying to fix this.

Thanks!
  • Hi, dartman, and welcome to the User BB!

    This sounds like a simple configuration error.  It seems strange that you have DNS resolution to "192.168.1.1" - if that's coming from an internal DNS server and you don't have a route to the Astaro, I wonder if you don't have another device that's the default gateway for your network or ???

    Although you may want to obfuscate your real IPs (like 64.x.y.101 and 192.168.z.1), please show precisely what IPs are where, including the mail domain.

    Cheers - Bob
    PS Ping behavior is regulated on the 'ICMP' tab of 'Network Security >> Packet Filter', but the message you showed above indicates that the ping couldn't be routed correctly.
  • In reply to BAlfson:

    Bob has some good points; also check your IPS settings (disable if necessary to test), and see if you have SMTP Proxy enabled, you may try disabling that temporarily as well (that could interfere with your telnet session you are using) -- these will help you narrow things down a bit, but I'm leaning towards a basic configuration issue as Bob said.
  • In reply to BrucekConvergent:

    Anytime someone uses "obfuscate" in a sentence, I am inclined to follow thier advice!

    The domain I am trying to telnet on port 25 to is mail.gomezmaylaw.com, which thier DNS records have this pointing to 64.22.219.165.

    The 192.168.1.1 is the internal address of my Astaro gateway, and this is the IP that is tagged on the "Destination host unreachable" on the ping.  I would expect the ping to fail, as I wouldn't beleive a lot of admins would allow there servers to be pinged.  The ping looks like this:

    ----------------------------------------------------------
    PING MAIL.GOMEZMAYLAW.COM

    Pinging MAIL.GOMEZMAYLAW.COM [64.22.219.165] with 32 bytes of data:

    Reply from 192.168.1.1: Destination host unreachable.
    Reply from 192.168.1.1: Destination host unreachable.
    Reply from 192.168.1.1: Destination host unreachable.
    Reply from 192.168.1.1: Destination host unreachable.

    Ping statistics for 64.22.219.165:
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 0ms, Average = 0ms
    ----------------------------------------------------------

    My public IP is 64.22.204.18, which is also the IP that resolves to mail.butlerins.com 

    I have disabled IPS, and there was no change in the behavior either.  I watched these logs intently for problems when I was troubelshooting, and I did not see anything.

    I did change the ICMP settings to allow everything, but that is not really related to the problem IMO.

    I did notice that this address is on the same ISP as my company, and I contacted the ISP to see if there was any routing, blocking, or anything keeping traffic flowing between these two IP addresses and we did not find anything there either.

    I appreciate the suggestions... does anything here give you any additinal insight?  Are there any logs I am missing to review?

    Thanks!
  • Since you are using the SMTP Proxy, my guess is that you've got it in transparent mode and it is intercepting the telnet calls.  Try turning this off on the advanced tab.
  • In reply to Scott_Klassen:

    I am sorry I wasn't clear, but I am not using the SMTP proxy.

    Thanks!
    Scott
  • Let's try something else in an attempt to narrow this down.  We'll see if it is just that domain.  Try 
    telnet smtp.gmail.com 25


    FYI, I can telnet to gomez just fine.

    Any other device upstream of the Astaro, like another firewall by chance?

    Update:  I did a check on your IP at dnsstuff and got back 
    BACKSCATTERER 127.0.0.2 "Sorry 64.22.204.18 is blacklisted at www.backscatterer.org/ http://www.backscatterer.org
      I see the same thing at mxtoolbox.  If this is a dns blacklist that Gomez uses, then that would account for the problem that you're seeing.
  • Scott, I still don't think the problem is that Scott's being rejected at the attorney's mailserver.

    Scott, from WebAdmin, 'Support >> Tools', ping their mail server both by IP and FQDN.  I bet both work fine.  If so, then my first guess is that you have a DNS configuration problem inside your network.  Do you have things configured like one of the suggestions in DNS Best Practice?

    Cheers - Bob
    PS To get your IP off the backscatter list, configure your anti-spam or mail server to not accept emails for non-existent addresses; at present, it appears to be accepting them and returning them as non-deliverable.
  • I know many ISPs block port 25 traffic.  Could it be as simple as that?

    -Bob
  • OK, one other thought.  In looking at this again, it seems that DNS is working fine, but the Astaro doesn't have a route to the IP.  What is the netmask on the External interface?

    Cheers - Bob
  • In reply to Dartman340:

    I did notice that this address is on the same ISP as my company, and I contacted the ISP to see if there was any routing, blocking, or anything keeping traffic flowing between these two IP addresses and we did not find anything there either.


    Ahh...therein lies the issue (I hope -- it'll make me look like a genius if it is [Smile] ).

    I have seen this happen before at a customer site.  They install a new ISP service, with a new router, and suddenly they have trouble sending / receiving all sorts of traffic (like you, email is usually the first thing they notice is not working) to another site that used to work fine under their old ISP.  They call us -- We find that the other site is on the same ISP, and that's the common issue -- there's nothing else "special" about the site that they can't communicate with.

    We hassle the ISP about routing issues, etc. and they don't see anything wrong in their edge / core equipment... then I dig into their (the customer's) router (the last time, it was an older Cisco T1 Router, a 1600 series I think, so yeah, it's been a while).  I see an IOS command missing that is normally on all newer equipment, "ip classless."  Turns out, enabling that, fixed the whole thing.  See Route Selection in Cisco Routers - Cisco Systems for more info ... if you are using a different kind of router, well, look for a function that performs a similar task.  Also, bear in mind, the remote router (the other end) may be misconfigured this way, and that would have the same result.

    The other possible cause is probably an issue with the ISP, but I'd rule out the above first...  If I'm right, donate 10 bucks to your favorite charity [Smile]

    BTW, if this is over your head, ask your ISP is there's an issue with routing to supernets (this is what IP CLASSLESS on a Cisco router fixes) on their network... they should be able to take it from there.  You can link them to this thread if you like, I think I might have painted a picture here...
  • I want to start of by saying that I am amazed and grateful for so many replies and experts helping me through this problem!

    As far as the ping from the Astaro, the name "mail.gomezmaylaw.com" returns the following:
    "Ping check did not deliver a result, because of a probably non-existing ip address / hostname"
    However, when I ping 64.22.219.165, I get some weird results:
    PING 64.22.219.165 (64.22.219.165) 56(84) bytes of data.
    From 64.22.219.217: icmp_seq=1 Destination Host Unreachable
    From 64.22.219.217 icmp_seq=1 Destination Host Unreachable
    From 64.22.219.217 icmp_seq=2 Destination Host Unreachable
    From 64.22.219.217 icmp_seq=3 Destination Host Unreachable
     
    The 64.22.219.217 is the address on my DMZ.  What gives?  I would assume that this would be the address of the Astaro?

    There is no upstream device, other than an Actelis router that provides our EIS. I do not have control over this device, and this device has not been changed in 5 years or more.  I should mention that I also have both an inbound and an outbound Zixmail encryption appliances (behind the Astaro), but my testing should have effectively bypassed them.  We also just added these last October, well into the issue with this domain.

    I was concerned about the backscatterer.org "blacklist" (loose term), but I have verified that this company is not using them as any sort of RBL.  I investigated our software and it looks to be confgiured to drop any emails without any response.  I am not too fond of this group from what I have read.

    I reviewed the DNS best practices thread, and this appears to be exactly how we are configured.  I am going to give it a second look just to make sure.  These Astaro units (they are actually in HA) have had very little configuration changes in the past 3 years, so it would be a good idea to refamiliarize myself with every aspect of the configuraiton anyway.

    The netmask on the External Interface is 255.255.255.0.  I am not sure how this is related, but I am open to anything.

    It definately seems to be a routing issue and not a DNS issue.

    Thanks!
    Scott
  • Excellent observation Bruce!  I will email this infomraiton to the ISP and the cleints IT folks and see if they can lend some insight into the problem.

    Thanks!
    Scott
  • In reply to Dartman340:

    Scott, now that you've given the external mask for your Astaro -- unless you guys have a full class C address range (not likely in the USA unless you are a large corporation or run a hosting service) from your ISP, that's probably the problem... verify that your subnet masks are correct per the ISPs configuration information.

    This is really sounding like a routing issue, and not an Astaro issue, per se.
  • In reply to BrucekConvergent:

    One additional tidbit of info; it's not well documented, but any additional IPs you have configured on a single interface (unless in separate VLANs) beyond the 1st one, on an Astaro should have a /32 mask -- I've seen issues when this was not done... in your case I'm thinking incorrect subnet mask or router misconfiguration.
  • Wow... I feel like I am getting close to the solution, but I am still missing something.

    Here is my definitions:
     
    DMZ [Up] on eth2 [64.22.219.217/32]  
    MTU 1500 

    Internal [Up] on eth0 [192.168.1.1/24] 
    MTU 1500 
    Auto-created on installation 
      
    External (WAN) [Up] on eth1 [64.22.204.18/29] 
    MTU 1500 · DEFAULT GW 64.22.204.17 
    Added by installation wizard 

    My ISP gave me the correct subnet, which they said should be a /29.  We have a range of IP addresses going from 64.22.204.16 to 64.22.204.22 (I think).  I am asking them to verify this.

    It definately looks like our firewall thinks the 64.22.219.165 is on our DMZ for some reason.  I even tried disabling it as an interface, but that did not work either.

    Any more thoughts?

    Thanks!
    Scott