Floating rule matched but firewall doesn't respond

clarknova

pfSense 2.4.5

Multiple WANs configured but only one connected and is default route. If I add a pass rule on the WAN interface to pfSense's web UI it works as expected. But if I remove the pass rule on the WAN and add a pass rule on the Floating tab with or without selecting the interface, the log shows that the packets passed, but the web UI does not load. tcpdump shows the incoming packets but no outgoing packets.

The floating rule is pretty simple:

pass log quick inet from <noc> to (self) flags S/SA keep state label "USER_RULE: Pass NOC to pfSense (rtr01)"

But it doesn't work. The rule on the WAN interface works as expected:

pass in quick on vmx1 reply-to (vmx1 192.0.2.1) inet proto tcp from 203.0.113.51 to any port = 4443 flags S/SA keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"

I prefer the floating rule for simplicity sake, rather than adding pass rules on each of the separate interfaces, but I'm not sure why this isn't working. Any pointers?

clarknova

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.

johnpoz

So your not doing nat? If so you would need your port forwards before any firewall rules would work.

jimp

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.

clarknova

@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.

clarknova

@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?

clarknova

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.

jimp

Are you sure it's public?

The reply-to entry on your rule is 192.0.2.1 and that is not a publicly routable subnet.

johnpoz

yeah 192.0.2 is used for documentation - are you obfuscating it?

clarknova

@jimp said in Floating rule matched but firewall doesn't respond:

Are you sure it's public?

The reply-to entry on your rule is 192.0.2.1 and 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.

johnpoz

I can ping that IP..

clarknova

@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.

johnpoz

Well that would make zero sense ;)

If for whatever reason rfc1918 rule was blocking it, ping should be included in that block.

clarknova

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.