Floating Rules Not Applying to pfSense

[artooro]

According to https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html under "Potential Uses" it states "Another way to use floating rules is to control traffic leaving from the firewall itself. Floating rules can prevent the firewall from reaching specific IP addresses, ports, and so on."

But I cannot get this to work. I've tried several variations of the rule but no matter what I've tried, the rule is never hit.
Testing by running the command curl -v --interface 192.168.1.1 http://example.com

[Bob.Dig]

@artooro That is meant to be on WAN outgoing, as an exception. Normally only incoming traffic is filtered.

[artooro]

@bob-dig yeah tried that too

[Bob.Dig]

@artooro Here is one example of many from my machine.

Spoiler

[Bob.Dig]

@artooro Blocking outgoing on LAN would only block something originating from another interface, e.g. WAN.

[johnpoz]

@artooro said in Floating Rules Not Applying to pfSense:

Floating rules can prevent the firewall from reaching specific IP addresses, ports, and so on."

So you want to stop something from leaving the firewall, even the firewall. Then that would be a floating outbound rule on the wan interface..

Really the only rule I do that for being a good netizen is block outbound rfc1918..

So example

See the rule in my floating tab.. it is block (red X) on the wan in the outbound direction (see the little arrow in a circle).. It is set as quick (2 double green arrowheads) and it set to log (little hamburger with checkmarks)

So I try and ping some rfc1918 address this not on my local networks, so per routing pfsense would send this out the wan.

Fails, and is logged as blocked.

Also keep in mind if you tried to do something, that was allowed you would have created a state. Which are evaluated before rules, so yeah blocking something after the state has been created - you really need to make sure no states exist for that traffic before your block rule would take effect. You could either kill any specific states, or all of them. Wait for them to timeout on their own, reboot the firewall is the oh there is a spider in my house, burn down the house response to removing states ;)

Now if I disable that rule, see how its grayed out.

Now if I ping I just get timeouts.. And notice if I sniff on my wan, traffic actually left the want trying to get to 192.168.42.42

Maybe if you actually gave some details of what exactly your attempting to block we could show rule to do that.

Common mistake users make is they test something, it works, then they test it again right after they create a block.. And yeah their rule isn't even evaluated because there was a state already that allowed the traffic, which allowed it - even with your block.