Floating rule matched but firewall doesn't respond
-
I am able to create rules in both the Floating tab and the WAN tab that appear identical using pfctl -sr:
pass in quick on vmx1 reply-to (vmx1 192.0.2.1) inet proto tcp from <noc> to (self) port = 4443 flags S/SA keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View" pass in quick on vmx1 reply-to (vmx1 192.0.2.1) inet proto tcp from <noc> to (self) port = 4443 flags S/SA keep state label "USER_RULE: Pass NOC to pfSense (rtr01)"If I disable the rule on the Floating tab I am able to reach the web UI on port 4443. If I enable the rule on the floating tab then the web UI doesn't respond. Something is broken here.
-
So your not doing nat? If so you would need your port forwards before any firewall rules would work.
-
If the rules look identical then the problem isn't in the rule. It's somewhere else in your ruleset. The rules are processed in a different order depending on where they are in the ruleset.
-
@johnpoz said in Floating rule matched but firewall doesn't respond:
So your not doing nat? If so you would need your port forwards before any firewall rules would work.
No NAT, just trying to reach the web UI on its public address.
-
@jimp said in Floating rule matched but firewall doesn't respond:
If the rules look identical then the problem isn't in the rule. It's somewhere else in your ruleset. The rules are processed in a different order depending on where they are in the ruleset.
Interesting. If I don't block RFC1918 addresses on the WAN then I can reach the web UI. But my source address is not rfc1918, and I can verify this by both the source address in the pass rule, with tcpdump, and with the firewall logs.
What would case the rfc1918 rule to block a valid publicly-routable address?
-
However I am using a socks proxy. Could this be a factor? pfSense sees the connection from the public IP address of my ssh server, so I don't see how it could be unless there is some filtering happening above the IP layer.
-
Are you sure it's public?
The
reply-toentry on your rule is192.0.2.1and that is not a publicly routable subnet. -
yeah 192.0.2 is used for documentation - are you obfuscating it?
-
@jimp said in Floating rule matched but firewall doesn't respond:
Are you sure it's public?
The
reply-toentry on your rule is192.0.2.1and that is not a publicly routable subnet.I substituted that for the real address. I've attached the unedited output of the firewall log. PUB03 is the WAN. The Source and Destination addresses in the log match the public IP addresses of my socks proxy and pfSense WAN, respectively.
-
I can ping that IP..
-
@johnpoz said in Floating rule matched but firewall doesn't respond:
I can ping that IP..
That's expected. I can ping it too, but only if I'm not blocking rfc1918.
-
Well that would make zero sense ;)
If for whatever reason rfc1918 rule was blocking it, ping should be included in that block.
-
I think I have this solved, partly. One of the disconnected interfaces on pfSense is in the same subnet as 104.37.148.83, so that's maybe going to cause a problem, although I don't see replies going out that interface, maybe because it's disconnected.
The other mystery is why disabling the rfc1918 filter causes the wan to be reachable from that subnet.
