Can't forward HTTP
-
anchor "userrules/*" all
pass in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto tcp from any to any port = 4000 flags S/SA keep state label "USER_RULE"
pass in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto udp from any to any port = 4225 keep state label "USER_RULE"
block drop in quick on re0 reply-to (re0 174.112.12.1) inet proto tcp from any to any port = microsoft-ds flags S/SA label "USER_RULE"
block drop in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto tcp from any to any port = microsoft-ds flags S/SA label "USER_RULE"
pass in quick on re0 reply-to (re0 174.112.12.1) inet proto tcp from any to 172.16.1.10 port = imaps flags S/SA keep state label "USER_RULE: NAT Forward IPv4 IMAPS to main computer"
pass in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto tcp from any to any port = imaps flags S/SA keep state label "USER_RULE"
pass in quick on re0 reply-to (re0 174.112.12.1) inet proto icmp all keep state label "USER_RULE"
pass in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto ipv6-icmp all keep state label "USER_RULE"
block drop in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto tcp from any to 2607:f798:804:93:5026:e137:17be:8959 flags S/SA label "USER_RULE"
pass in quick on re0 reply-to (re0 174.112.12.1) inet proto tcp from any to 172.16.1.10 port = ssh flags S/SA keep state label "USER_RULE: NAT Forward IPv4 SSH to main computer"
pass in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto tcp from any to any port = ssh flags S/SA keep state label "USER_RULE"
block drop in quick on re0 reply-to (re0 174.112.12.1) inet proto tcp all label "USER_RULE"
block drop in quick on re0 reply-to (re0 174.112.12.1) inet proto udp all label "USER_RULE"
block drop in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto tcp all label "USER_RULE"
block drop in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto udp all label "USER_RULE"
pass in quick on re0 reply-to (re0 174.112.12.1) inet proto tcp from any to 172.16.1.10 port = 4000 flags S/SA keep state label "USER_RULE: NAT "
pass in quick on re0 reply-to (re0 174.112.12.1) inet proto udp from any to 172.16.1.10 port = 4225 keep state label "USER_RULE: NAT "
pass in quick on re0 reply-to (re0 fe80::217:10ff:fe91:41f) inet6 proto tcp from any to 2607:fea8:4cdf:fbe5:76d4:35ff:fe5b:f5fa port = http flags S/SA keep state label "USER_RULE: Web site"
pass in quick on bge0 inet from 172.16.1.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
pass in quick on bge0 inet6 from 2607:fea8:4cdf:fbe5::/64 to any flags S/SA keep state label "USER_RULE: Default allow LAN IPv6 to any rule"
pass in quick on re0 reply-to (re0 174.112.12.1) inet proto tcp from any to 172.16.1.10 port = http flags S/SA keep state label "USER_RULE: NAT "So if firewall rules are processed top down, first match wins, why is it that IMAPS and SSH work and HTTP doesn't?
No. Check the firewall rules in addition to the NAT rules. Post what you have done.
Maybe you have a rule in front blocking the traffic before its allowed.
@KOM:
There is no problem with pfSense and NATs/port-forwards. You are doing something wrong.
-
how freaking hard is it to paste a screen shot of your rules and nats Really…
-
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.
