Postfix Woes following re-install

OS type and version Debian 11
Webmin version 2.021

Hi all

I have been searching around and can’t seem to find the issue. Up until I completely messed up my system the other day, it has been running quite happily on Debian 10.

Long story short, I performed a full wipe of my VPS, installed a fresh Debian 11 and then installed Webmin/Virtualmin GPL from the documentation. I deliberately didn’t import/restore any settings from my old install and, whilst I can recieve mails quite happily, I am no longer able to send.

When I try to access an external SMTP server with Telnet, it times out. Which led me to believe it might be something with FirewallD - I didn’t have FirewallD installed previously (I had been running without re-install for a number of years).

For a sanity check, I spoke with my VPS provider who confirm that they don’t block 25 at all. Which makes sense really, as I was sending emails without issue before the re-install…but it didn’t hurt to check.

Following some searching around, I ran the following command:

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp -m tcp --dport=25 -j ACCEPT

But this doesn’t appear to have helped me…would anyone have any suggestions?

Many thanks in advance

You may have triggered fail2ban. Check for banned ip’s
Virtualmin has firewall setup, that shouldn’t needed to be touched it.

Thanks for replying. I just went to the fail2ban section on Webmin and it’s offering me to “Start the fail2ban server”, so I don’t believe it’s setup to run.

Is firewalld setup like this, I setup a frresh debian 11 and fail2ban is going by default.

Yep, exactly like that

so that show smtp and smtps have rules. so really there should be issue with firewall. You could turn it off for a second and see if you connect just to verify.
use the Test Email Server here,

I restarted the server and now fail2ban is active - Although there is nothing in banned ips that I can see.

Testing my server on the mxtoolbox showed an SMTP Banner Mismatch, so I was able to resolve that by altering my reversedns settings on my host control panel. Now it gets green ticks across the board.

I shutdown firewalld and I still couldn’t telnet out on port 25 - I will go back to the provider I guess.

ping the server, just make sure your computer is not pinging the wrong IP.

Ping works fine - I’ll try and get hold of the VPS supplier - I suppose I could potentially use gmail as a relay ?

If MXtool Test Email Server is showing a connection then its working. You need to resolve why your computer can’t telnet to server. Are you using the correct port.
this is what I get to my server.

I think you may have misunderstood the issue. Incoming to the server is OK - It’s outbound traffic that is failing.

My provider have told me the port 25 from my server to the internet isn’t blocked, but I am unable to connect to anything with port 25 out on the internet.

So, when I send an email out - It timesout connecting to the relevant SMTP server and fails.

Based on the feedback from my provider, I took it to mean that there was something on the server that was stopping port 25 getting out onto the internet.

Ok, misread what you meant. Good luck.

The firewall on a Virtualmin system does not block any outgoing traffic. It is not the firewall on your Virtualmin system. (Unless you did something custom and explicitly disallowed some outgoing connections.)

It is almost certainly a firewall at your hosting provider. Most block port 25. Some can be convinced to open it on request, others can’t and you have to use a mail relay service.

It is not fail2ban. Again, it does not do anything with outgoing connections. There is no possibility of it being involved in this problem.

You say you can’t send out? Is this from a client on the server like Usermin or Roundcube or from an external client? Both?

Nothing in the logs other than the timeout?

Makes the most sense. A dropped packet isn’t answered in any way. I just looked up tracepath. It looks like it accepts -p for port. I don’t see an option for protocol though so it might not be too definitive. But, you might want to check further.

EDIT: Found this and tried it. Worked from my Debian 11 box.

sudo tcptraceroute 443

root@main:~# sudo tcptraceroute 443 Running: traceroute -T -O info -p 443 traceroute to (, 30 hops max, 60 byte packets 1 ( 0.358 ms * * 2 ( 0.451 ms 0.542 ms 0.543 ms 3 ( 0.990 ms 0.955 ms 0.916 ms 4 ( 13.054 ms 13.020 ms 12.985 ms 5 ( 12.877 ms 12.913 ms 12.879 ms 6 ( 12.962 ms 12.781 ms 12.707 ms 7 ( 12.631 ms ( 12.643 ms ( 12.607 ms 8 ( <syn,ack> 12.681 ms 12.585 ms 12.689 ms

I actually assumed that was the case, which is why I reached out to them to check…Like I say though, the confusing thing is that before I re-installed everything was working normally. Which is why I queried here, although I did speak to them anyway and they said that nothing is blocked in or out.

I am waiting for them to come back to me again, but in the meantime I just setup a relay through gmail to get me up and running.

I appreciate all of the responses and I pretty confident that the datacenter are blocking it, despite the VPS provider telling me otherwise.