Traffic flowing outbound although denied
-
@michmoor that is a different state, see the source port of 51804
While your block is source port 52200
States are looked at before rules, if there is an active state then traffic would be allowed.
Kill that state.. But until the state goes away, then yes traffic coming from that IP on that source port to that dest IP and port would be allowed. Other traffic, from different source port would be denied..
-
@johnpoz ok understood. So then the other worry is why is there even a state for this anyway. The state has been present which seems to be for 5 days but my DMZ rules have been unchanged for weeks.
The most recent activity that i did was to blow away the 22.05 environment, reload CE and then migrate to the Plus branch. While on the CE branch i put back my original configuration using my backup .xml file which had the unchanged DMZ rules.
So although its a different port, the state shouldve never existed. -
@michmoor At some point were there were default rule of any any for example that state could of been created. Once the state is there, creating a block doesn't make the state go away.
Whenever you create a block rule - its good practice to search through your states to make sure there is no states that would allow what your trying to block.
Kill the state..
-
@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.
