Open port still being blocked by "Default deny rule"

knox203

Hey all,

I have some servers routing through pfSense with a 1:1 P-ARP NAT. One server in question seems to be having a difficult time keeping the port open through the firewall. Here are some images of my configuration along with the actual blocks shown in the firewall log. Can anyone please assist me in finding out why pfSense is blocking these packets when I've told it to accept them?

The first image is the 1:1 NAT I setup for the server in question giving it it's own IP.
The second image is the Virtual IP I setup for that IP.
The third image is the NAT Port Forward for port 80 to that server.
The fourth image is the rule created by the NAT port forward.
And finally the fifth image is showing the actual packets being blocked by the firwall. I've logged the rule to show the allowed packets, and it looks like it's accepting most data going to port 80 minus these sparse packets. I know they're legit because the originating IP is coming from another block of IP's we own.

Please help me!!! Thank you ;D

1-1.png_thumb

virtual_ip.png_thumb

nat_80.png_thumb

rule_80.png_thumb

blocked.png_thumb

MadX

Hi,

I have the same kind of problem see my post :
http://forum.pfsense.org/index.php/topic,14257.0.html

Any help ?

thanks

knox203

So there's nobody out there who can provide the slightest explanation / direction to get this fixed? Maybe at least tell me it's user error :P … could I have something in the illustrations configured incorrectly?

Thanks!
- Adam

knox203

Nothing? Nobody ain't got nothin'?

cmb

See http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection%2C_why%3F

knox203

See, now that's what I'm talking about! Thanks a ton, cmb. I looked pretty heavily through the docs, but obviously I guess I didn't look hard enough… tough to come to the conclusion that the blocks are harmless until reading this. I've seen many people explain this exact issue, maybe this is something that should be made more apparent since it affects everyone using the firewall and I'm sure there's a bunch more people wondering about this same (is it safe to call it a bug?) symptom.

Thanks again,
- Adam

cmb

It's not a bug, it's just how stateful firewalls work. Some will hide it from users to avoid confusion, but that's the wrong thing to do. You'll see the same with any stateful firewall that doesn't hide blocked out of state traffic. One of the Cisco PIX firewalls I manage logs about 50,000 such entries a day on a network with only a few hundred hosts.

knox203

First of all, I appreciate you sharing your expertise with me (us) cmb, I feel a bit more confident in running this firewall knowing this!

Why would it be considered the wrong thing to hide all these innocent blocks when it seems to me that they just kind of get in the way? Is there any advantage by keeping them in the logs? I guess I'm just having a hard time understanding the point of keeping them…

cmb

PF can't differentiate a blocked out of state packet that is probably part of what was a valid connection (once it's out of the state table, record of that connection is gone). So we have no option to not log that traffic. I suspect what firewalls that hide that do is just not log dropped TCP with FIN set, unless their state table leaves states there for a while after the connection was closed. It would be possible with PF to drop but not log incoming packets with FIN set, though that's not exposed in the pfSense GUI and I wouldn't recommend it.

Occasionally out of state traffic getting blocked is indicative of a problem, though that's rarely the case.

Philosophically, if your firewall is configured to log everything it blocks, it should do that. That's the primary reasoning for my "that's the wrong thing to do" comment in my last post.