Unable to connect to any public IP on port 25 from pfSense itself
-
I have one pfSense installation (2.6.0 but the problem was also present on prior versions) where I am at loss to find why it won't connect to port 25 of any WAN facing SMTP. Simply telnetting to port 25 from the pfSense VM will fail (time out). I have several other firewalls which all work with similar configurations. I find no mention of the block in any log. The problem is that I can't setup notifications to an external SMTP like this (it works on the internal LAN though). What could be blocking access to port 25? Other ports other than 25 are reachable from the firewall so it's a specific issue regarding port 25. Also, I am able to connect to port 25 on any external IP from the internal LAN - it only fails while attempting connection directly from the firewall itself. This configuration is comprised of 2 pfSense VMs in CARP with (double) NATed private WAN IPs (10.0.0.x) behind another router (ISP). Everything else works as expected, just this port 25 issue is a major pain in the ass.
Thanks for any heads up!
-
@it_luke
I would suspect that's something wrong with the outbound NAT.
So show you outbound NAT page, please. -
@it_luke there is no default block in pfsense outbound, there are actually rules that allow the firewall to talk to anything outbound from the firewall itself.
cat /tmp/rules.debug
pass out inet all keep state allow-opts ridentifier 1000012115 label "let out anything IPv4 from firewall host itself" pass out inet6 all keep state allow-opts ridentifier 1000012116 label "let out anything IPv6 from firewall host itself"So unless you have some specific outbound rule in your floating tab, there is nothing in pfsense out of the box that would stop that..
-
@johnpoz Exactly, which is what has me stomped. No specific floating rules, no specific block rules on that port and it can't be the ISP's router as I can access any external IP on port 25 from the internal NATed network fine. The only thing which I can think of is that as I am using CARP IPs for the 4 double NATed IPs (10.0.0.1-4/24) to public IPs and NATing the LAN traffic on one of these (.1), while the 2 firewalls are using other IPs, possibly one of these other IPs (10.0.0.8 and 10.0.0.9) is being blocked on port 25 for some reason - but I find this rather unusual.
-
@viragomann The outbound NAT is working as expected - I have no issues in connecting the LAN machines to any of the public IPs on any port (including port 25) ad viceversa. The problem lies with the local WAN interface IP, but solely accessing port 25 from the firewall itself.
-
@it_luke said in Unable to connect to any public IP on port 25 from pfSense itself:
The problem is that I can't setup notifications to an external SMTP
To be honest you wouldn't need to use 25 outbound for this... I use 587 with gmail to send notifications from pfsense.
(double) NATed private WAN IPs (10.0.0.x) behind another router (ISP).
You sure whatever source IP your coming from on pfsense is not blocked at router in front of pfsense?
To be honest many an ISP unless a specific work sort of connection would block outbound 25, I can not use 25 outbound from my isp connection. But you say you can talk to smtp server via clients behind pfsense - but what IP are they natting to, vs what pfsense might use - you mention a HA setup with a carp address, etc.
-
@johnpoz In this case I need to use Microsoft's O365 EXO through an IP filtered SMTP connector which works only on port 25 and yes in fact to bypass the problem I am using another SMTP on a different port but I need to use the customer's M365 account with their EXO. Works fine on other pfSense setups, it's just this particular instance that has this issue. I will try directly from after the firewall with the same IP with another machine to see if there is some issue on the ISPs setup blocking port 25 from this other IP but as I said, I can connect through pfSense NAT to port 25 without issues - though it's NATing on a different CARP IP.
-
@it_luke After all that - but you think its pfsense blocking 25?
though it's NATing on a different CARP IP.
-
@johnpoz Yeah, that was my bad! Turns out it is their ISP as the extra IPs used (not the CARP ones) are not in the SNAT and they block port 25 (and other ports too!) on these extra IPs.
-
@it_luke said in Unable to connect to any public IP on port 25 from pfSense itself:
@johnpoz Yeah, that was my bad! Turns out it is their ISP as the extra IPs used (not the CARP ones) are not in the SNAT and they block port 25 (and other ports too!) on these extra IPs.
Not just your ISP.
Nealy all ISPs block outgoing TCP connection to port 25.
Except to their own 'ISP' mail server.The thing was - and still is today - that port 25 is used by mail clients like Outlook365 or Thunderbird to send mail.
That utterly wrong. And yeah, I know, our ISP leached us to use port 25. That was a bad call.
Port 25 is meant to be use by server servers only, for the originating server to the destination mail server.Use port 587 TCP for the old fashioned outgoing mail, which can offer also TLS if supported.
What will be needed is authentication, like POP or IMAP to GET your mail.
Or be modern and use 465 TCP direct, as it is TLS from the first bit.If you have your own mail server behind pfSense, then outgoing mail traffic to a port 25 TCP on the net (any other mail server on the Internet), might be an issue with most ISPs - they actually don't want you to run a mail server I guess.
-
@gertjan There was an internal mail server (Exchange) but it was decomissioned after EXO cutover migration which is the reason for all of this. EXO allows creation of connectors but you can no longer select the port as with classic Exchange connectors - it just defaults to 25. Granted that port 25 ought to be used for server to server, this connector is also there for authenticated devices such as MFPs or similar so it is not unusual to use it for notifications from devices. The important thing is that we found the reason and we'll find a solution (probably get the ISP to unblock the port on that IP as it is a business contract and by contract there should be no limitations to connectivity as with the other IPs being used - it's not residential).
