static ip - incoming ports 25 and 80 blocked from last friday

[#1]

I've been running an smtp server for many years, listening quite happily on port 25.It routes internally to postfix running on an old centos box.

The last email I received from the outside world was at 15:30 on friday 11/4/25. I've spent the whole weekend investigating it turns out incoming connections on port 25 are not being forwarded to my internal network.

I also have IIS listening on port 80 (hosting just my intenal CA's certificate revocation list); this appears to be invisible to the outside world too.

So far:

• incoming HTTPS connections to IIS on port 443 are working
• port 587 is forwarded to the centos box and appears to be listening.
• https://dnschecker.org/port-scanner.php verifies other ports are open and forwarded; it seems only 25 and 80 are blocked.
• Turning off both Plusnet's broadband firewall and my router firewall makes no difference.
• I tried changing the forwarding rules so external 26 -> internal 25 and 81 -> 80, which both work fine, but obviously I cannot ask other people to send me smtp mail on a non-standard port.

My guess is some network security policy has been put in place on friday preventing unencrypted connections to plusnet customers (or at least me) from being let through. I think what bugs me most is that I was given no notice of this change; if I had known in advance I could have spent some time getting a letsencrypt certificate for port 587 so mails would come in that way, but obviously that is not in place yet and we are currently getting no mails.

I opened a ticket with CS over the phone yesterday, who said the network team have a 3-5 day (i.e after easter) turnaround for queries like this, then an automated bot closed it! Today I opened another ticket over the phone and they suggested I ask here, as there are more technical people that might understand the problem and be able to suggest solutions, workarounds, or additional diagnostics to narrow down the source of the problem. So far I can try:

1. swapping out my huawei router for the original plusnet one
   - can't imagine how old it is, but it would eliminate another potential source of the problem. I don't hold out much hope though.
2. getting a wildcard letsencrypt certificate installed on centos to allow incoming mail connections on 587
   - not an instant or trouble-free soluiton as my current dns provider does not support the letsencrypt dns challenge method

Anything else the gods of plusnet can suggest?

Cheers

Andy

[#2]

Port 80 isn't blocked for me.

[#3]

@andy_p2 

Turning off both Plusnet's broadband firewall 

Was it previously on ? and did you 'bounce' the PPPoE connection after changing as changes wont take effect until the PPPoE is reconnected.

As @dvorak says , whilst I dont use port 25 or 80 AFAIK no ports are blocked as long as the BB firewall is off

[#4]

Yes, it had previously been set to "low" for years, and everything was working fine, 25 and 80 are not blocked:

If Broadband Firewall has been set on LOW, this is to protect your router from inbound traffic on the following Internet PORTS:

53, 111, 135, 137, 138, 139, 445, 515, 1080, 1433, 3128, 3306, 6000

After I turned it off I disconnected power to the openreach box for an hour to ensure it got a fresh connection.

I'll try putting it back to low now, and the connection can be resetting again while I dig out the old plusnet router.

Cheers

[#5]

dug out my old router - Technicolor TG582n FTTC (does anyone else remember those?)

Luckily it still had the authentication saved, so I put the port redirects into it, same result:

external	internal
80	80	blocked
443	443	open
25	25	blocked
587	587	open

If I switch 80 and 443 round, external 80 is still blocked and external 443 (now routed to 80 internally) is open, thus proving the ports are being blocked externally and open on my machines.

external	internal
80	443	blocked
443	80	open

Where do I go from here?

[#6]

Assuming you're on the same IP address as you've posted from I've just ran nmap against your IP and this is what it shows for me so concurs with what you're seeing:

nmap x.x.x.x
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-04-15 21:22 UTC
Nmap scan report for x.x.x.x
Host is up (0.013s latency).
Not shown: 993 filtered tcp ports (no-response), 3 filtered tcp ports (host-unreach)
PORT STATE SERVICE
83/tcp open mit-ml-dev
443/tcp open https
587/tcp open submission
990/tcp open ftps

I think I've spotted the problem though, let me get back to you tomorrow.

[#7]

That's great news.
The stuff about certificates and port 587 is irrelevant really, I need 25 open to receive emails however we slice it.

Cheers

[#8 · Accepted solution]

That's done the trick, 25 and 80 are showing open now from nmap:

nmap x.x.x.x
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-04-16 07:55 UTC
Nmap scan report for x.x.x.x
Host is up (0.015s latency).
Not shown: 994 filtered tcp ports (no-response)
PORT STATE SERVICE
25/tcp open smtp
80/tcp open http
83/tcp open mit-ml-dev
443/tcp open https
587/tcp open submission
990/tcp open ftps

Nmap done: 1 IP address (1 host up) scanned in 4.31 seconds

Not quite sure how it got itself in that state, need to have a look at that and double check to make sure no-one else is affected.

[#9]

Thank you for fixing port 25, at least emails are starting to come in again.

I am, however, still not getting a connection on ports 83 or 85 (2 web cameras) - I notice you could see 83, and it was working intermittently yesterday, but I cannot see it this morning. 85 has not conected for a while. Any idea what could be going on? I can move them onto different port numbers if you think others would be more reliable.

One other thing, once again my support ticket (raised over the phone, updated by me) has been closed by a bot with "We are closing this ticket as we are no longer able to support queries raised online." I've just been called by someone from CS though, and explained what happened; he is going to try to stop that happening in future.

[#10]

These are the ports that are blocked with the firewall set to low so anything except these should work unless the router has another use for them:

destination-port [ 53 111 135 137 138 139 445 515 1080 1433 3128 3306 6000 ];

Port 83 on your connection is working for me, 85 is not. Certainly worth a try on another port that isn't in the above list. I always try a high numbered port as it keeps it away from the commonly used ports.

I've flagged the issue with the bot to one of the call centre managers as that doesn't seem right.

[#11]

yes, 83 is working for me in a browser now, maybe it was somthing funny in the port scanner I was using. I'll have a play with the camera on 85 but it really isn't a show-stopper 🙂

Someone from the call centre called me, he said advisors had been putting the ticket in the wrong queue and it sounds like some training was going to be useful.

Thanks again for your help; it's such a relief to have email working again.

Cheers

Andy