Can't forward HTTP
-
Yes, if you have a rule that blocks all TCP just before your NAT rule, you're going to have a bad time.
This would have been easy to spot with a simple screenshot of the WAN rules.
-
Here they are. The firewall rules are in 2 parts.
-
So anything tcp/udp below this rule would be blocked
Rules are evaluated top down, first rule to fire wins. So here your blocking ipv4&6 tcp/udp here, so those rules below are never going to be seen.
Move your rules above that rule, or just delete that rule and let the default rule block stuff you do not allow in rules. Your not even logging on that rule. So what traffic would you see blocked on your wan?
Your rules to * dest are bad idea on wan that is for sure as well!! They should be limited to the IP your forwarding too.
-
I didn't create that rule and have no idea about why it's there. I'll try moving that rule to the bottom and test later, when I have time. On my way to work now.
-
Well it sure is not a default, and it sure didn't create itself ;) You running something like pfblocker that can create rules?
-
No, I'm not running pfblocker.
I suppose that rule won't cause any harm, if left at the end of the list. However, I assume pfSense has an implicit deny all rule. In other firewalls I've worked with (IPchains, IPTables and Cisco), there's always an implicit deny all and you'd only create a specific deny all rule, if you want something more, such as logging.
The only rules I've added are the ones to pass various protocols.
BTW, moving that rule to the bottom cleared the problem.
-
Yes, that hidden rule is called the Default Deny rule. There has been debate over the years as to whether it should be hidden at all, or just unavailable but visible so you can see it but not edit or delete it.
-
Lots of UI issues with that. For instance the default deny rule is not at the bottom of the rule set. It is at the top without quick set. So where should it be displayed?
People have a difficult enough time with this stuff already.
-
If visible, it had better be stuck at the bottom, so as to avoid a problem like mine. I don't need to see it, as long as I know it's there. Firewalls should always start with deny all to which exceptions are added.
-
Lots of UI issues with that. For instance the default deny rule is not at the bottom of the rule set.
Lots? I would think that the rule's placement within the master rule list would be irrelevant when it comes to a graphical representation of a static rule.
So where should it be displayed?
At the bottom where it logically belongs. I'm not sure what problem is solved by hiding it, but it certainly confuses new users to the point where they feel like they have to create their own rule. The little blue info bubble is too small for most to even notice it, and it's collapsed by default.
-
Lots? I would think that the rule's placement within the master rule list would be irrelevant when it comes to a graphical representation of a static rule.
Ummm… Don't rules generally run top to bottom?
-
Don't rules generally run top to bottom?
Yes but the first-match/last-match functionality of the Quick option completely changes how the rule is triggered.
What I was trying to say was that, regardless of where in the actual list of rules (that you can see via pfctl -s rules from console), as far as a visual representation goes in the GUI, the default deny rule should be visible at the bottom of the GUI list as a visual indicator. It's not technically hard to do and it would solve a problem that seems to appear on a weekly basis.
-
I personally believe that anyone who really cares can look at pfctl -sr. It might be nice to have a Diagnostics > Automatic Firewall Rules display or something.
Default deny rules were just one example.
-
I also like the idea of being able to toggle display of the automatic rules created, for example the dhcp rules that get enabled when you enable the dhcp server. maybe it is confusing to some not seeing the default deny that is always there?? But I have never seen a firewall that was not default deny. That is really a given that if there is no allow rule its denied.
But what I am sure of is that rule was not automatically created, the OP at some point created that rule. Or allowed it to be created by some package like pfblocker and then removed the aliases that would of been included, etc. ??
The point of the default deny not having quick set does present some problems with a logic to parse the rules correctly for graphical display I guess.
