Traffic flowing outbound although denied
-
@johnpoz State is killed. DMZ rules do not have a permit to any port so this is a very strange event here.
Im very sure this is a particularly unique thing to pfsense (or pf) as typically when deny rules occur in other platforms existing states are torn down if matching.
Regardless, is there a cleaner way of making sure if a new block rule is applied to an interface then there shouldnt be any existing state on the firewall?
Firewall: NetGate,Palo Alto-VM,Juniper SRX
Routing: Juniper, Arista, Cisco
Switching: Juniper, Arista, Cisco
Wireless: Unifi, Aruba IAP
JNCIP,CCNP Enterprise -
@michmoor re: block rules and states...
https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#firewall-troubleshooting-statesone can manually reset states at https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-states-reset.html
The "cleaner way" is probably to set a default block rule, and allow only the needed ports. That way states aren't opened until allowed. This is actually the default on all interfaces except LAN, because LAN has a default "allow to any" rule and other interfaces have no rules thus a default block only.
-
@michmoor said in Traffic flowing outbound although denied:
platforms existing states are torn down if matching.
not always true - have seen many a firewall over the years where that does not happen. Also have seen were all states are killed - which is horrible implementation.. If the firewall is going to kill states, the only states that should be killed are the states the rule matches..
All I am saying is from what you posted there is a state that would allow that specific traffic, no matter what rule you put in place to block it - until that state is removed.
So if you kill that state, are new states being created where you have a block rule in place?
-
@steveits said in Traffic flowing outbound although denied:
The "cleaner way" is probably to set a default block rule, and allow only the needed ports. That way states aren't opened until allowed. This is actually the default on all interfaces except LAN, because LAN has a default "allow to any" rule and other interfaces have no rules thus a default block only.
What you are saying makes sense.
Below is my ruleset.
From this, I just don't see how that flow was active.
As I posted, 5 days ago, the only maintenance done was to reimage the firewall back to 22.05 and load my config.xml which has the rule set you see above.The only way what your suggesting makes sense is if the backup XML saves state information which wouldn't make sense.
-
@johnpoz said in Traffic flowing outbound although denied:
not always true - have seen many a firewall over the years where that does not happen. Also have seen were all states are killed - which is horrible implementation.. If the firewall is going to kill states, the only states that should be killed are the states the rule matches..
Agreed. The majority of my experience would be on the SRX line where I have seen the behavior of killing an active state when a block rule is added.
To your other point, once the state was killed, no new states were created.
-
@michmoor said in Traffic flowing outbound although denied:
To your other point, once the state was killed, no new states were created.
and your seeing blocked traffic?
-
@johnpoz said in Traffic flowing outbound although denied:
and your seeing blocked traffic?
Yes I am seeing blocked traffic
-
What's in the 'approved apps' alias?
Do you have floating rules? Interface groups? UPnP?
Are you still seeing states created there? You can use pfctl at the CLI to see what rule is creating them.
Steve
-
@stephenw10 Hey stephen,
the approved apps alias contains the following
Do you have floating rules?
- yes the ones created by pfBlockerNG
Interface groups?
- No
UPnP?
- No
Are you still seeing states created there?
- Since I deleted the state, it has not come back and I see the rules rejecting the flow.
I think leaving this in the mystery bucket is all thats left. I truly dont understand how that flow was allowed to pass with no permit any/any when my dmz rules are very specific and have remained unchanged for a while.
-
Mmm, there must have been a rule there are some point but without a state to check there no way to know. If it's blocking as expected now there's not much more you can do.
Steve
-
I really like the output of pfctl -sr from either the console or debug, run command from the web interface.
It shows me the all the rules, in the order they are added/evaluated, and all the different rules (floating, interface, interfacegroups, etc) are in one list. I find it easier to manually parse or walk but you need to be familiar with raw pf rules/configs.That's my preference, others with more experience in the GUI or the XML config may find a different way better.
