Not sure about Floating & Interface Group rule behavoir
-
I am not sure about the behavoir of Floating rules and Interface groups. Below why and where I am confused.
Despite that I am using floating rules and interface groups right now, I feel a bit uncomfortable. The reason that I try here to get an exact description / better understanding from what is exactly happening.
Not clear to me 1
In the documentation I read
The firewall does not automatically add reply-to on floating rules in the inbound direction as it does for individual interface rules. Thus, floating rules have the same problem as interface groups: Return traffic passed by states created from floating rules will always exit the WAN with the default gateway, a reply packet cannot automatically return out a non-default WAN through which it entered the firewall.However traffic can arrive on a (v)lan from two sources
- the WAN
- some other (v)lan
And with that in mind IMHO the sentence in the documentation is quite confusing. What part from the description refers to the WAN and which part refer to any other source !!??
So what is the behavoir if the source is some other (v)lan and what is the behavoir in case the source is a WAN and perhaps also what is the behavoir it there are multiple WAN's?
Not clear to me 2
The documentation mention "in you select multiple interfaces" and then I wonder:
- what is the behavoir if you select just one interface and
- what is the behavoir if you select multiple interfaces
And again I refer here to internal (v)lan interfaces
Not clear to me 3
Assume I define an out rule for interface-y allow access to interface-z subnet scope HTTPS & SSH.
Then the expectation is that that will do the job. However the phrase ^does not automatically add reply-to^ makes me cautious. So if that will not work, how to solve that !??Not clear to me 4
If ^Quick^ is not selected the behavoir changes from “first match wins” to “last match wins”.
Yep I understand that however: Which other rules do match ^not quick^ rules ??As example if I place a rule at the begin of the floating rules saying ^for any interface, block everything for any traffic out not permitted by any other floating rule having destination interface-x-subnet.
I assume that nothing will enter subnet-x not described in the floating rule tab.I assume that the match between the ^not Quick rule^ and some other rule further down is NOT related to e.g, the selected interface (a match is a match whatever interface is selected in both ^related^ rules.
Some background / use cases
Just for info, Note that there are multiple reasons for me to use floating rules (and interface groups) to mention:
- Security the Idea to limit access to e.g. the greenzone in every vlan is wrong IMHO. I like to limit access for all vlans using floating rules
- Things I would like to block generically, should go to floating rules
- Anti lockout rules should be here
- rules related to multiple vlans should be in an interface group
- rules related to high performance data streams should be processed first (=> in the floating table)
-
@louis2 said in Not sure about Floating & Interface Group rule behavoir:
Not clear to me 1
In the documentation I read
The firewall does not automatically add reply-to on floating rules in the inbound direction as it does for individual interface rules. Thus, floating rules have the same problem as interface groups: Return traffic passed by states created from floating rules will always exit the WAN with the default gateway, a reply packet cannot automatically return out a non-default WAN through which it entered the firewall.That's true.
The reason is, the reply-to tag is added by the rule, which passes the incoming traffic, and only to packets coming in on an interface, which has a gateway defined on. The gateway has to be unique. However, both types, floating and interface group rule can be applied to multiple interfaces. Hence the gateway would not be unique.
However traffic can arrive on a (v)lan from two sources
the WAN
some other (v)lan
And with that in mind IMHO the sentence in the documentation is quite confusing. What part from the description refers to the WAN and which part refer to any other source !!??As I implied above, it's just on an interface, which has a gateway defined. This is not necessarily the WAN. pfSense basically doesn't differ. The reply-to can be applied to any other interface as well.
Not clear to me 2
The documentation mention "in you select multiple interfaces" and then I wonder:
what is the behavoir if you select just one interface and
what is the behavoir if you select multiple interfaces
And again I refer here to internal (v)lan interfacesIf you select multiple, the rule is just applied on multiple interface.
If you allude to reply-to, it isn't applied even if you select only one interface.Not clear to me 3
Assume I define an out rule for interface-y allow access to interface-z subnet scope HTTPS & SSH.I guess, with "out" you mean direction = out. But if so, this is not applicable. If you define an out allow rule on y to interface-z subnet, the rule might match no packet, since no one with destination z subnet will go out here.
Not clear to me 4
If ^Quick^ is not selected the behavoir changes from “first match wins” to “last match wins”.
Yep I understand that however: Which other rules do match ^not quick^ rules ??As example if I place a rule at the begin of the floating rules saying ^for any interface, block everything for any traffic out not permitted by any other floating rule having destination interface-x-subnet.
I assume that nothing will enter subnet-x not described in the floating rule tab.Same as above, since you select direction = out, selecting other interface than x might not make much sense.
However consider, that also interface and group rules are probed before the non-quick floating rule is applied. So if any of these passes the traffic, the floating has no effect.
-
One of my problems is the definition of what is a wan / what is a gateway and what is an (v)lan interface.
As I see it all v(lan)'s including the WAN's are connected to the firewall core. In my thinking WAN, LAN and OPTx are just names but essentially the same 'a channel towards the firewall core. LAN is just 'opt0'
So 'out' is from the core towards the interface (whatever type / name) and 'in' is from the interface towards the firewall core / kernel.
Quite confusing there is the behavoir of the interface (whatever type) address, in a normal level-2 situation all (v)lan addresses are part of level2 and can be reached. Only partly so in case of a firewall where the interface is representing two things the address itself and level-3 functionality on top of that address.
What ever, from your reaction my impression is that (v)lan interface (I personalty refer to as gateway) and gateway seems to be things to distinguish. Where it is still not completely clear to me what the exact difference is.
What ever if I read the documentation the copied phrase raises far more questions to me than it answers !!
I still feel the need to test all situations to be sure that the thing behaves the way I think it behaves. Examples related to:
- source a wan
- destination wan
- source an interface
- destination an interface
- one interface selected vs multiple interfaces selected
Also note that WAN is just one of the interfaces in the interface selection menu, completely supporting my idea that there is no difference between wan and any other interface apart from name and a few additional things.
Here an example of one of the thing which confuses me
Three rules which should allow management of the green zone
- the first rule related to the management interface = > allow access to the greenzone
- the second rule related to the greenzone intrface => allow traffic from managment to enter
- the third rule => allow to replay to the managment lan
However .....
- It seems to work without the third rule !!?? (see documentation sentence The firewall does not automatically add reply-to on floating rules in the inbound direction)
- I do not like the third rule since there is no port filtering possible since I do not know which ports will be used / where used
-
Here another test
Two rules here
- allow access to my graylog vm
- block access to my graylog vm
The intention of the test is to verify if the in rule can work without an explicit return rule. If the first rule is not taking care of the return path, graylog would not be accessible due to the second rule.
However graylog is accessible which proves that the firewall does take care of the return path.
I just wanted to be 100% sure that this works.
And also like to emphases that the documentation in at least IMHO is not clear -
@louis2 said in Not sure about Floating & Interface Group rule behavoir:
The intention of the test is to verify if the in rule can work without an explicit return rule. If the first rule is not taking care of the return path, graylog would not be accessible due to the second rule.
However graylog is accessible which proves that the firewall does take care of the return path.
This is pretty normal filter rule behavior, as it's doumented in pfSense book.
The first match wins. If a pass rule matches pfSense adds a state for this connection to its state table and response packets to this are allowed by this automatically.
-
There are a lot of things I did always take for granted, up to the moment I had a few things which did not work for some reason and I did start reading the documentation as related to floating rules ..... which really did confuse me start doubt yourself.