Some Firewall rules not working after upgrade to 24.03 - rules between subnets are not passed through

[johnpoz]

@Udbytossen Without knowing exactly your data flow paths, and which interface is which here, since you didn't include the interface those rules are on.

I would switch back to floating states.

https://www.netgate.com/blog/state-policy-default-change

See if that corrects the problem your seeing.

If that fixes it, then look into the details of why so you can adjust so that you can use the more secure bound to interface states if possible. This may require a look to your actual flow of data.

I can see your doing policy based routing with your gateway set on that last rule going to torguard. Not sure the point of the to lan address rule. If I wanted stuff to get to the lan from from this network your routing out your vpn connection, the destination should be lan subnets, not lan address. All that rule is going to allow is access to the pfsense lan IP. nothing else in the lan would be allowed by that rule.

This seems like a odd rule, why would devices need access to the lan address if they are on the tv subnet, wouldn't they access services on pfsense like dns or ntp on the tv address? Which you allow.

[Udbytossen]

@johnpoz
That rule was just a try for me to see if I could get any thing through from one subnet to another.

Changing it to Floating states - solves the issue. - So thank you very much.

Buit then I'm hmmmm - Since they chose it as the standard - I think it could be nice to lkearn more about settings for the Interface Bound States - since they set is as default - there's something about it :-)

But thanks for the reply

[johnpoz]

@Udbytossen yeah now that you know that floating works, you would have to determine why your bound to interface states are not.

In your typical

network x -- pfsense -- network y

This should not be a problem. But users do all sorts of funky policy routing and other configurations that end up with some sort of asymmetrical flow.

Why they decided to change from floating to interface bound vs allowing users to change to interface bound on their own not sure. But sometimes you just have to live with some tickets and users having problem to get to a better config/setup.

Do we create problems in low percentage of the users setups, and have a very large percentage of users now on the better interface bound states. Or do we make it purely optional require user intervention and end up with very low percentage of deployments using the better config?

Notice how many threads about this isn't working after the dhcp move to kea. They blogged about, clearly went over that its preview and features not yet implemented, many users don't read the info provided.. But they did click the button to move to it, once it was in their face.. But didn't even look at the release notes before they did, etc. Or if they did, they didn't understand that hey I am using that feature that is not yet available in kea. They just saw hey isc is EOL..

I take it you didn't read the release notes before moving to 24.03? Since it right there in the release notes as well about the state change. Or did it just not click that "Multi-WAN policy routing" pertained to your setup? A vpn client connection, means you are multi wan, even if you only have 1 actual internet connection from 1 isp.

If I were you, my take away would be oh I should look into why and figure out how to move to interface bound states.. Even if was a bit painful to draw my attention to it.

Kind of how your isp will just turn off your connection if they want you to contact them.. They know for sure you will, because you might not be reading your emails, or their posts about hey users need to do xzy, etc.

[stephenw10]

@johnpoz said in Some Firewall rules not working after upgrade to 24.03 - rules between subnets are not passed through:

Why they decided to change from floating to interface bound vs allowing users to change to interface bound on their own not sure. But sometimes you just have to live with some tickets and users having problem to get to a better config/setup.

There was significant debate internally about that. But in the end pfSense is a security product and interface bound states are inherently more secure.

[johnpoz]

@stephenw10 said in Some Firewall rules not working after upgrade to 24.03 - rules between subnets are not passed through:

interface bound states are inherently more secure.

I agree, if users want to use a less secure setup - then that is on them.. But I do see many more threads sim to this one in the future ;)

[stephenw10]

Yup, unfortunately I think you're right. It's interesting to note though that anyone hitting this has a setup that would not have worked before floating states were first added in (I think) 2.5.

[jimp]

@johnpoz said in Some Firewall rules not working after upgrade to 24.03 - rules between subnets are not passed through:

Why they decided to change from floating to interface bound vs allowing users to change to interface bound on their own not sure. But sometimes you just have to live with some tickets and users having problem to get to a better config/setup.

It was a security decision. There were some problem scenarios brought to our attention where floating states could theoretically allow someone with control of a WAN segment to re-route local traffic for DHCP WANs. While difficult to pull off in a practical manner, it was compelling enough that we felt the best default for a security product was the more secure option of the two going forward. We could have only switched the default when there was a DHCP WAN but that would have been even more confusing with it being selectively applied.

Notice how many threads about this isn't working after the dhcp move to kea. They blogged about, clearly went over that its preview and features not yet implemented, many users don't read the info provided.. But they did click the button to move to it, once it was in their face.. But didn't even look at the release notes before they did, etc. Or if they did, they didn't understand that hey I am using that feature that is not yet available in kea. They just saw hey isc is EOL..

We also put up a blog post about this change when it went in nearly two months before the release:

https://www.netgate.com/blog/state-policy-default-change

That also explains why the decision was made, some of the potential problems, etc.

We have found more problem scenarios since then and have updated the release notes and docs to match (e.g. VTI in certain filter configurations).

We didn't just update the release notes either, all of the docs have been updated with state policy information and cross-references in relevant areas.

[johnpoz]

@jimp yeah I hear yeah.. Thanks for the info.

I tried to follow that statement with some logic to why it would be done.. I get it, some times you have to do things that even if painful for some is good for all.

[jimp]

@johnpoz said in Some Firewall rules not working after upgrade to 24.03 - rules between subnets are not passed through:

@jimp yeah I hear yeah.. Thanks for the info.

I tried to follow that statement with some logic to why it would be done.. I get it, some times you have to do things that even if painful for some is good for all.

Yeah, there are some scenarios that were working that should have still been working and don't (e.g. VTI), and some things we knew would break (e.g. ECMP), but most of what I've seen people report as "broken" have been poorly designed or implemented things on their local setup, like multi-homed machines they didn't even realize were talking in one interface and out another. Those were lucky to be working at all, and still could work with a couple config/rule changes, but it's best to fix them up properly and eliminate the problem.

[johnpoz]

@jimp said in Some Firewall rules not working after upgrade to 24.03 - rules between subnets are not passed through:

but it's best to fix them up properly and eliminate the problem.

Exactly!!! Completely agree, even if a bit painful for some. I can foresee increase in tickets to TAC..