Help with Floating Rules

[joesl]

Hello people,

I'm relatively new to pfsense so please, bear with me.
My current understanding could be summarized by:

• Floating rules are evaluated before Interfaces rules
• If I select "quick" for my floating, they act like interface rules and stop at the first match; if they don't match they go till the last floating and then evaluate Interface rules.
• Unlike interface rules, which create a state which is valid also for the return trip, floating rules don't

Based on the above I don't understand how can this work.

Floating (interfaces: all; direction: in):

Int OPT1:

With the above I'm able to SSH into hosts under OPT1. But given the argument above, they would have been stopped since the trip back from OPT1 to LAN would be blocked by the lack of reply-to rules and the OPT1 rule would deny it. Why then it works??

The reason as to why I am looking into floating is because my "Admin_Clients" resides in different networks so it'd be convenient to have 1 rule as opposed to many in all the ints.

Thanks!

[johnpoz]

@joesl said in Help with Floating Rules:

blocked by the lack of reply-to rules and the OPT1 rule would deny it. Why then it works??

Because it doesn't work that way.. Why would you think it needs a reply to rule.. The state lets it return.

[joesl]

Am I misunderstanding the meaning of: "Floating rules in the inbound direction, applied to multiple WANs, will not get reply-to added as they would with individual interface rules, so the same problem exists here as existed with interface groups: The traffic will always exit the WAN with the default gateway, and not return properly out the WAN it entered."
from https://www.netgate.com/docs/pfsense/book/firewall/floating-rules.html

Thanks.

[johnpoz]

So you have multiple WANS? Or you users on just different local networks.

You need reply-to rules when answer is coming back from wrong IP..

If you talk to 1.2.3.4 from internet (wan1) to get forwarded to say 192.168.1.100 but answer goes back via different wan 4.5.6.7 then no its never going to work. But that doesn't happen when 192.168.1 is talking to 192.168.2

[joesl]

Different local networks. Got it, so it's not true what I wrote above:

Unlike interface rules, which create a state which is valid also for the return trip, floating rules don't

[johnpoz]

floating rules create states. when the traffic is allowed.

[joesl]

Thanks a lot johnpoz. I arrived at that (wrong) conclusion in order to explain another behavior which now I again don't understand (I explained it via the lack of states).

Take the example above:

Floating rule with all interfaces selected and direction in:

If a client matches here, then it will get allowed; state created; period. end of the story regardless of any other rule below (because it's a quick rule) or in the interfaces tabs.

Under, I have another floating rule like this (it's a fail-safe rule to prevent misconfigurations in other int tabs); again direction in and all interfaces are selected:

If I add this, then I can't ssh from a client in Admin_Clients to a host in OPT1. If I disable it, I can. I don't understand why I get blocked. On top of that, when I get blocked I see states created in the allow rule as CLOSED:SYN_SENT.

Thank you for your time

[johnpoz]

What are the interface rules where the client is coming from?
Lan?
Also some odd stuff can happen with Negate rules.. Always better to block specific... You would prob have to look at the rules directly with
https://www.netgate.com/docs/pfsense/firewall/viewing-the-full-pf-ruleset.html

It that is really going on to explain it.. I can try and duplicate it.. If admin_clients table does not contain the source IP then the reject rule would reject them for sure.

[joesl]

The admin_client alias contains the client which I'm using for testing (172.16.0.123, for example purpose).
So, the admin client which I'm using is within a LAN network which has these rules:

1. allow dns from lan net to lan address
2. allow ntp from lan net to lan address
3. allow icmp from lan net to lan address
4. block everything from lan net to RFC1918
5. allow everything from lan net to any

Actually, I don't fully understand why we should worry of the rules in the interface "lan" where the admin_clients resides since the floating should apply before.

In the meantime, I'm trying to decypher the content of pfctl -sr, thanks for the tip!!

[johnpoz]

Just clear understanding was my goal, rules would come into play without quick, etc. etc. Screenshots are way better ;) Sometimes users say they have rule X but its really Y, etc.

I can try and duplicate - but working on another project right now..

[joesl]

Thank you for that. No hurry..

Screenshot of LAN rules (so for this example let's say LAN is 172.16.0.1/24, OPT1 is 192.168.111.1/24, Admin_Client contains 172.16.0.123 and I'm trying to ssh from 172.16.0.123 to 192.168.111.123):

By the way, I've tried to extract the relevant bits of OPT1 from the pfctl -sr output:

... probably pfsense stuff?
scrub on OPT1 all fragment reassemble
block drop in log on ! OPT1 inet from 192.168.111.0/24 to any

... my floating allow rule
pass in quick on OPT1 inet proto tcp from <Admin_Clients> to 192.168.111.0/24 port = ssh flags S/SA keep state

... my floating deny fail-safe rule
block return quick on OPT1 inet from ! 192.168.111.0/24 to 192.168.111.0/24 label

... rule in the interface OPT1 to block everything
block return in quick on OPT1 inet from 192.168.111.0/24 to any label

[joesl]

AAAA...

I've seen the issue, the deny floating rule was in direction=any... my bad, sorry for taking up your time!

[johnpoz]

Well that would explain it.. I would normally suggest you stay away from floating and put rules on the interfaces directly. Less likely to mess up.. Unless you had 100's of interfaces or something.. Just put the rules on the interfaces - very cut and dry simple look to what the rules are that way.

[joesl]

Thanks!