Using the mxtoolbox and grc.com port testers, I can see that all of the ports required for MiaB are open, but MiaB reports that none of the mail ports are open.
Why might this be?
MiaB setup configures the needed ports when installing it.
- To know what ports you have open run:
ufw status verbose
Additionally, some CLOUD server providers enable a NAT, Firewall, Security Group(s) … by default at your Admin panel there then … if that’s your case, just check your allowed ports there match the ones you have allowed in your UFW.
Hope this helps.
@just4t MiaB is otherwise functioning just fine, there is just something that is causing a discrepancy between the system status checker and the actual status.
Note that I am not running on a cloud server and the network has a firewall.
@openletter the firewall on the network is blocking the ports, then. Also, be aware that basically all home internet providers will block out the necessary ports regardless of what you do on your end
@DonaldKBrown. I don’t mean to be rude, but in all seriousness, did you read my post? I stated that the ports are reported open by services outside my local network. Given this statement, how would it be possible that my gateway is blocking those ports?
I also recommend asking questions before stating general things that, as in my case, have nothing to do with me. My ISP does not block any ports.
Did you ever find out more about this issue? We are a cloud service provider and are looking to offer hosting of this solution. Any Idea where to look for logs besides mail.log for detailed system check logs?
This is what I’m getting when running the checks:
Everything else seems to be working fine other than the false check failures.
mail.log
Oct 14 14:17:44 lmtp(19329): Info: Connect from 127.0.0.1
Oct 14 14:17:44 lmtp(19329): Info: Disconnect from 127.0.0.1: Connection closed (in banner)
Oct 14 14:17:44 lmtp(19329): Info: Connect from 127.0.0.1
Oct 14 14:17:44 lmtp(19329): Info: Disconnect from 127.0.0.1: Connection closed (in banner)
Oct 14 14:17:44 box postfix/submission/smtpd[19331]: connect from box.zcloudservices.com[127.0.0.1]
Oct 14 14:17:44 box postfix/submission/smtpd[19333]: connect from box.zcloudservices.com[127.0.0.1]
Oct 14 14:17:44 box postfix/submission/smtpd[19333]: SSL_accept error from box.zcloudservices.com[127.0.0.1]: lost connection
Oct 14 14:17:44 box postfix/submission/smtpd[19333]: lost connection after CONNECT from box.zcloudservices.com[127.0.0.1]
Oct 14 14:17:44 box postfix/submission/smtpd[19333]: disconnect from box.zcloudservices.com[127.0.0.1] commands=0/0
Oct 14 14:17:44 box postfix/smtpd[19332]: connect from box.zcloudservices.com[127.0.0.1]
Oct 14 14:17:44 box opendmarc[8030]: ignoring connection from box.zcloudservices.com
Oct 14 14:17:44 box postfix/smtpd[19332]: lost connection after CONNECT from box.zcloudservices.com[127.0.0.1]
Oct 14 14:17:44 box postfix/smtpd[19332]: disconnect from box.zcloudservices.com[127.0.0.1] commands=0/0
Oct 14 14:17:44 box postfix/submission/smtpd[19331]: lost connection after CONNECT from box.zcloudservices.com[127.0.0.1]
Oct 14 14:17:44 box postfix/submission/smtpd[19331]: disconnect from box.zcloudservices.com[127.0.0.1] commands=0/0
Oct 14 14:17:44 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, TLS handshaking: SSL_accept() syscall failed: Success, session=<tbNcGFTOaNl/AAAB>
Oct 14 14:17:44 managesieve-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured, session=<07RcGFTOtI9/AAAB>
In my case, the only thing I was doing differently was running behind a firewall on a private network.
I am not aware anyone has resolved this issue, as some will occasionally post having the same results I had.
When MiaB is installed per the installation instructions, including and especially to a fresh install of Ubuntu Server 18.04 which has a public IP address directly assigned to it, there shouldn’t be any such issues, so my only guess is you have something in your hosting environment causing this problem.
Considering that I have full control over our hosting environment, I’m determined to figure this out. I do understand what you’re saying about the firewall. The only thing it’s doing is NAT from the private IP to public and vice versa, the rest is allow any any. I can’t imagine these other hosting companies statically assigning a public IP to their virtual servers so there has to be something else going on.
There is a ton of stuff I don’t know regarding underlying web infrastructure and DC networking. I know that when I would connect my MiaB directly to my modem, it fixed all the problems (except rDNS).
I always assumed that whatever they have in the DC performs the same as whatever is on the rest of the switches on the web.
Does it help you any to install to someone other host’s VPS and try to spot some difference?
Yeah, I might rent one and try if it gets to that point. I’m pretty confident that once I get some input from the rest of my team at the data center, we’ll be able to figure it out and I’ll post the solution. Everything is functioning fine, I’m just neurotic about seeing any red or warnings. LOL
Same issue. Static IP business line running MIAB and status checks all timeout or unknown or not set but at times works. Just SSL certs renewal was an issue so far…
I use my ISP provided DNS (WOW) as the two dns server on pfsense and then just opened all the nat rules to the miab device as the instructions said.
This post is just to share that there are a few of us here.
This is likely due to NAT reflection/hairpin. Some routers/firewalls handle this differently. My MiaB server basically always tells me the ports are not open, but they are. Cisco Enterprise Routers do not do nat reflection. MiaB is trying to hit the “WAN” IP and then go back inside the network to check for open ports but Cisco Enterprise (and possibly others) do not allow this to happen.
There are a bunch topics on this in the cisco forums but I really dont care, I just end up ignoring the messages.