Clarification on floating rules ?

[prayuth01]

Hi,

I'm not really sure if I understand the concept of floating rules correctly. OPN has nothing regarding this topic in its documentantion, but PF states the following:

1) Filter traffic from the firewall itself
2) Filter traffic in the outbound direction (all other tabs are Inbound processing only)
3) Apply rules to multiple interfaces
4) Apply filtering in a "last match wins" way rather than "first match wins" (quick)
5) Apply traffic shaping to match traffic but not affect it's pass/block action

Is this exactly the same for OPN ?
The following things aren't really clear to me:

2) Till now, I filtered my outbound traffic from single VLANs from their interface tab in the rules menu. Is this the wrong approach ? For example: I created some port aliases with what I wanted to be permitted outbound and allowed this with a rule that inverted the RFC1918 to make it match on all destinations, but the private IP-address-range.

4) What should last match mean exactly ? Does it mean that if I would like to block traffic from LAN to 0.0.0.0 and if  this rule is followed by a rule, that for example just blocks traffic from LAN to a specific IP, then this rule will match and not the "block LAN to 0.0.0.0" rule ? Except that this example makes no real sense, for me this concept seems a bit strange.

If someone could clarify on this, I would be grateful. ufabet

Thanks.
Wayne

[franco]

Hi there,

I would say the concepts have not changed here.

All rules tabs other than floating are inbound-only, so that's one's first distinction if one needs outbound filtering, but most of the time one doesn't.

2) This is confusing in terminology, you said outbound but hopefully meant incoming VLAN traffic from the perspective of the firewall.

4) Last match wins is an idiosyncrasy of the pf packet filter. "first match / quick" is the normal mode of operation for most firewalls but it was added later to the filter in historical terms. The original rule evaluation was based on "last match" where rules could be written ordered as unspecific to super specific. If you disable "quick" on floating rules, you will gain this behaviour for that particular rule.

The most useful way to use last match is to have a floating rule (which is evaluated before the other rules tabs) in last-match mode that acts as a placeholder for more specific rules in the individual tabs and yields authority to a later match there.


Cheers,
Franco

[kyferez]

Hi there,

I would say the concepts have not changed here.

All rules tabs other than floating are inbound-only, so that's one's first distinction if one needs outbound filtering, but most of the time one doesn't.

2) This is confusing in terminology, you said outbound but hopefully meant incoming VLAN traffic from the perspective of the firewall.

4) Last match wins is an idiosyncrasy of the pf packet filter. "first match / quick" is the normal mode of operation for most firewalls but it was added later to the filter in historical terms. The original rule evaluation was based on "last match" where rules could be written ordered as unspecific to super specific. If you disable "quick" on floating rules, you will gain this behaviour for that particular rule.

The most useful way to use last match is to have a floating rule (which is evaluated before the other rules tabs) in last-match mode that acts as a placeholder for more specific rules in the individual tabs and yields authority to a later match there.


Cheers,
Franco

Franco,

This discussion has very much confused me...

a) Why would you want to separate Inbound and Outbound rules by forcing us to put Inbound rules in the Floating section and Outbound rules in the Interface section? It makes it harder to manage and keep rules straight!

b) I have been under the impression all along (because it made sense given that Floating rules apply before Interface rules) that Floating rules would apply to all interfaces first, and then the specific Interface rules would apply, and that both Floating and Interface specific rules could be for Inbound & outbound rules. Could you explain the intent / reasoning for this design?

c) You said "if one needs outbound filtering, but most of the time one doesn't", and I'm unclear as to why you say this because best practice for any corporate network is to have a DMZ where you NEED Explicitly defined inbound and outbound rules with specific allowed sources, destinations, and ports. Could you explain the thought behind your statement?

Thanks!
Travis

[franco]

Hi Travis,

Sorry, it was not meant to confuse...

a) Why would you want to separate Inbound and Outbound rules by forcing us to put Inbound rules in the Floating section and Outbound rules in the Interface section? It makes it harder to manage and keep rules straight!

No, all interface tabs are inbound only. Floating rules can be inbound, outbound or both (via the direction setting).

b) I have been under the impression all along (because it made sense given that Floating rules apply before Interface rules) that Floating rules would apply to all interfaces first, and then the specific Interface rules would apply, and that both Floating and Interface specific rules could be for Inbound & outbound rules. Could you explain the intent / reasoning for this design?

Historic precedent. Interface rules were first and modelled after a normal firewall. And then someone thought it would be wise to add floating, which can do everything and more. I don't favour this, but since it has been like this for many many years one would have to assume it generally works as designed.

c) You said "if one needs outbound filtering, but most of the time one doesn't", and I'm unclear as to why you say this because best practice for any corporate network is to have a DMZ where you NEED Explicitly defined inbound and outbound rules with specific allowed sources, destinations, and ports. Could you explain the thought behind your statement?

I think you are confusing what inbound and outbound means.

For pf, the packet filter, inbound and outbound direction means:

1. Receiving interface, so where the packet entered the firewall.
2. Sending interface, so where the packet exits the firewall.

This has nothing to do with the direction of the packets you want to filter accordingly. Normally, enforcing policies is on (1.) and rarely on (2.), because why would you forward something through a firewall if you are going to discard it when it is ready to exit?

I hope that explains it a bit better.


Cheers,
Franco

[kyferez]

This has nothing to do with the direction of the packets you want to filter accordingly. Normally, enforcing policies is on (1.) and rarely on (2.), because why would you forward something through a firewall if you are going to discard it when it is ready to exit?

I hope that explains it a bit better.


Cheers,
Franco

Yes, it does, and it negates most of my concerns. Thank you!

Travis