On 5/18/2018 10:42 AM, Alberto José García Fumero wrote:

Im trying to block spam (for instance, from
As far as I know, it's trying to pass as a message from my very net:

Transcript of session follows.
De:     Mail Delivery System <mailer-dae...@partagas.ettpartagas.co.
Para:   Postmaster <postmas...@ettpartagas.co.cu>
Asunto: Postfix SMTP server: errors from
Fecha:  Fri, 18 May 2018 10:10:39 -0400 (CDT)
  Out: 220 partagas.ettpartagas.co.cu ESMTP Partagas
  In:  EHLO
  Out: 250-partagas.ettpartagas.co.cu
  Out: 250-SIZE 15240000
  Out: 250-ETRN
  Out: 250-STARTTLS
  Out: 250-8BITMIME
  Out: 250 DSN
  Out: 503 5.5.1 Error: authentication not enabled

Session aborted, reason: lost connection

For other details, see the local mail logfile

but the MTA correctly rejects it as a fake.

It might not be good to describe what happened here as your MTA rejected the connection as a fake. If your MTA is configured to reject a connection because the EHLO contains your IP address (which is unlikely), that isn't what happened here.

Your MTA returned a 503 error to the sending server because your MTA is not configured to accept an AUTH login. 250-AUTH is not part of its response to the EHLO. Most mail servers accept AUTH only on port 465 or port 587.

I have created an alias list (rechaza) in the menu Firewall/Aliases,
where I put all the addresses known to be spammers, and tried to reject
them with the rule in Firewall/Rules/WAN

Action: Block
Interface: WAN
TCP/IP version: IPV4
Protocol: TCP
Source: (single hots or alias) rechaza
Destination port range: any

but I can not stop the spam right in the WAN interface.

If you take a look at Status > System Logs > Firewall and notice what you see for Source and Destination this can help you understand better how filtering and NAT works. For your WAN interface, Source will be the public IP of the origin of the packet. If there is no port forwarding configured for the destination port, no NAT occurs so the destination address will be your public IP. If port forwarding is configured for the destination port, then NAT does apply and the destination address will be your LAN IP. It helps to keep this in mind when developing rules.

It is a good idea to not be too specific with rules. Since you are running a mail server you must have port 25 forwarded to the mail server LAN IP. Because of NAT for port 25, specifying your public IP as the destination prevents the rule from matching. Because of NAT, to have a match you would need to have the mail server LAN IP as the destination.

You probably want to block the IP from going to any destination though regardless of whether the destination port is forwarded or not. So in your rule you want

Destination: any

instead of


If you were to add another LAN interface to pfSense in the future the rule will continue to match then as well.

If you are intending to block all traffic, not just TCP, from the source, you want

Protocol: any

On 5/18/2018 12:52 PM, Alberto José García Fumero wrote:

Could I create a rule saying, for instance: "reject packets originating
(apparently!) from the WAN address and directed to my WAN address? (as
they are trying to forge identity)

This is unnecessary. There is no way for a system on the Internet to establish a TCP connection that apparently originates from your WAN address.

If you are running a mail server or anything else that faces the Internet, hopefully you are using snort or suricata and are just trying to supplement with your own rules. There is no way you could maintain an effective list of addresses to block with just your own rules. You should also be using anti-spam measures on your mail server as well.

John J.
pfSense mailing list
Support the project with Gold! https://pfsense.org/gold

Reply via email to