Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're using a pfSense firewall with a static public IP. TCP port 25 is forwarded to the mail server on the DMZ, according exactly to the directions here. This works great for most senders, and email is successfully forwarded to the internal mail server address.

However, some legitimate senders are being blocked on port 25 at the firewall rather than port-forwarded to the email server. I know pfSense blocks stuff with expired/incorrect state, etc even on legitimate ports, but this is regular traffic from a known email sender that's getting blocked. No entries exist for the sender in the state table. I've also looked at the pfSense port forward troubleshooting guide with no luck.

I've captured the traffic from the external sender in question; it's TCP port 25 with a SYN flag and good header checksum, definitely being blocked at the outside interface but doesn't seem to look different from packets that are being forwarded properly.

Here's a log entry for the blocked sender:

pf: 2. 858929 rule 34/0(match): block in on fxp0: (tos 0x0, ttl 117, id 41529, offset 0, flags [DF], proto TCP (6), length 48) [blocked-sender-ip].34056 > [internal-dmz-email-ip].25: S, cksum 0x68f8 (correct), 3080958461:3080958461(0) win 65535 <mss 1460,nop,nop,sackOK>

And one for a successful sender that looks pretty similar:

pf: 288804 rule 51/0(match):  pass in on fxp0: (tos 0x0, ttl 111, id 34646, offset 0, flags [DF], proto TCP (6), length 48) [successful-sender-ip].2474 > [internal-dmz-email-ip].25: S, cksum 0xcf9c (correct), 1409725583:1409725583(0) win 65535 <mss 1460,nop,nop,sackOK>

Any idea what's going on here?

share|improve this question
up vote 1 down vote accepted

PFSense has a fre default rules regarding where traffic can come from on the WAN interface.

For example, you can tell it to drop any traffic on the WAN that has a private IP address (192.168, 10.0 or 172.0), because in a lot of scenarios you should never see a private IP on the WAN. However, also in a lot of cases you WOULD (if the pfSense is sitting INSIDE a network, rather than on the edge).

It will also block IP ranges that are not officially allocated to anyone, as they're supposedly never meant to be seen in the wild.

You can turn these options off under the Advanced menu in Configuration (I think it is, off the top of my head), or possibly in the WAN configuration screen.

I'm going to suggest that these two options are the place to start, because for whatever reason the traffic may be originating from a private IP range (mail filter, virus scanner, whatever) but hitting the WAN port, OR, a fresh block of IP ranges has been allocated and PFSense is not up to date with its listings.

share|improve this answer
Thanks, will give this a try ASAP... both sender and pfSense WAN should both be public addresses, but perhaps it's being routed strangely -- good place to start. – nedm Oct 1 '09 at 21:08
That did the trick -- the address in question is still apparently in the pfSense(v1.2.2)'s bogon net list, though according to IANA the range in question was assigned in 2008. Unchecking the "block bogon networks" option in the WAN interface configuration let it through. Thanks a ton! – nedm Oct 1 '09 at 22:01
Glad I could help. I never ticked that box, and now I'm glad! – Mark Henderson Oct 1 '09 at 22:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.