Auto blocking IP addresses when seding SMTP 1

[mrbusy]

I have a client with a Firebox X 500. Works pretty well for most things but for some reason it keeps auto-blocking ip addresses when sending out email. The firebox does NAT to the external ISP supplied address from the internal Exchange server.

In the log the only message that appears is "Temporarily blocking xxx.xxx.xxx.xxx", but no reason is given. This only seems apply to SMTP sent to some domains. The only fix I have found is to get the IP address of the recipient domains MX records then add it to the blocked exceptions list.

My initial thought was that the recipient domains mail server is trying to do some kind of verification by connecting back to the firewall and being seen as a threat, hence the block, but nothing helpfull appears in the log about ports being accessed or anything.

Anyone seen this before? Any help greatfully recived.

 

[gerbieIT]

I actually have the same problem sometimes. I found that the Intrusion preventation was blocking it out.

 

[mrbusy]

I discovered this problem was caused by the Auth protocol using port 113.
Most of the domains which were getting blocked were academic and using older Sendmail / UNIX systems which attempt to connect back on port 113 before accepting email. The firewall saw this as a hacker and blocked the IP address.

All I did was add a rule to the Firebox that blocked port 113 but did not automatically add the IP address to the blocked senders list.

Now, instead of getting blocked the recieving mail server tries to connect on 113, gets nothing back and times out after a couple of seconds. It then accepts the conneciton on port 25 and continues as normal.

Since making this change early last week the problem seems to have gone away.

 

[gerbieIT]

thanks for the ifo.

 

[kixtart]

Nice find! I ended up cheating. I relayed all outgoing email to my ISP's SMTP server. I always meant to go back and find out why, so thanks!

kixtart

 

[mrbusy]

I would check three things:

1) That the packet type is correct. So, for example, the rule doesn't expect to see UDP packets but receives TCP, and so still blocks them.

2) That the rule is set to enable and deny, not disabled.

3) That port 113 does not appear in your permenantly blocked ports list.