Confused about rule

michmoor

Gents/Ladies,
I have a fule where any traffic thats intended to go to any RFC1918 address will be blocked. After that rule there is a permit any/any with !RFC1918 as my destination. Everything seems to work but when i check firewall logs, i see dnies hitting my RFC1918 block rule but the description in the logs is wrong..

As you can see from teh screenshot, blocks are hitting the "Permit to internet" rule , which is getting blocked but in my firewall rules it should be hitting the "block internal".

Jarhead

@michmoor Those two rules are redundant.
No need for the !rfc1918. It's already blocked.

Curious, are those the only rules on that interface?
You would never get to the internet if they are.

johnpoz

@jarhead I agree with you those rules are odd. But he would still be able to get to the internet since 8.8.8.8 for example would not be rfc1918, and it the ! rfc1918 would allow it.

But I think his more curious question is why does the firewall log say the rule that blocked it permit to internet , when it should be the top rule block internal.

What is odd here is why are the evaluations exactly the same 6 active states, which on a block should really be 0 and exact same amount of traffic 628.03MB - that sure seems highly unlikely.

Something seems like your rules are messed up, had you copied a rule - maybe they didn't actually load when you reloaded?

I would clear all your states, and do a rule reload -- filter reload under status.

If still odd, then actually look at you rules for what the ID on the rules are, etc.
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html#viewing-the-pf-ruleset

Also not really a fan of ! rules, since you have a rule that already blocks rfc1918 - your bottom internet rule there should just be any.

There was previous issues and ! rules when there was vips involved, say the IP for example that pfblocker would setup 10.10.10.10 or whatever it was, etc.

Unless you have a really explicit need for using ! I would not use them, and if you do - then make sure you explicitly do some very extensive testing of them to make sure they are working as you intend them too.

michmoor

@johnpoz
To Johns point, Internet access does work .
The thinking for me goes, I want to block any traffic from leaking over to other private networks hence the RFC1918 block.
The second line is anything thats not meant for private networks gets sent out to the Internet.
I could make the rule a permit any/any as basically no private networks would be accessible which is the goal.
The reason for the !RFC1918 is because i wanted to be explict in what the rule is doing.

I checked the rule ID prior to sending this post and yep...traffic that is attempting to access a private range is being blocked by the Permit to internet rule...Super odd.

For the complete picture of the rules I have on this isolated network below is the screenshot.

johnpoz

@michmoor so your seeing different IDs for the 2 different rules.

So is working as intended now. After clear all states and reload of the rules.

You are seeing 2 different IDs for these rules when you look at the full ruleset.

michmoor

EDIT:
Double checked the ruleID as suggeted.
You are correct. Rule ID 1661208833 is the same for both the block Internal and Permit to Internet. Never seen that before...
Whats the fix? Re-create the rule?

I changed the rule to permit any any and got rid of the negate. Did a filter reload.

Seems to still be wonky.

Jarhead

@johnpoz said in Confused about rule:

@jarhead I agree with you those rules are odd. But he would still be able to get to the internet since 8.8.8.8 for example would not be rfc1918, and it the ! rfc1918 would allow it.

True but only if the devices themselves had 8.8.8.8 hardcoded as their dns. Otherwise the dns would have been blocked if it was assigned by dhcp.
Totally moot since his first rule allowed dns anyway.
That's what made me curious if they were the only rules.

johnpoz

@michmoor said in Confused about rule:

Rule ID 1661208833 is the same for both the block Internal and Permit to Internet.

That is odd for sure... Not sure how that could happen? But yeah a delete and then recreation of the rule should correct that..

edit:
Did you copy the rfc1918 rule, and then just edit to !?

rcoleman-netgate

@johnpoz if it's copied in the config file and then imported this can happen.

michmoor

@johnpoz
this is a new interface i brought up a few days ago. I dont recall copying from another interface.
If i did copy, then would you think that this is incorrect(buggy) behavior then? The option to copy rules from one interface to another is part of the code but the tracking ID should be changed in the process and it isnt.

I have since recreated the any any rule including the !RFC1918 negate. The rule ID is different now.
This was a very strange one. Thanks for pointing out to double check the tracking ID.

The good thing is that at the end of the day, the firewall was doing what it was supposed to do regardless if the metadata about the rule was incorrect.

johnpoz

@michmoor local data fallback, so this a ha pair?

Or that most likely refers to how you logged in, when updated, etc. So you radius auth failed?

michmoor

@johnpoz Not an HA pair. I do have radius set up for local login but i logged in as admin not using my radius account

rcoleman-netgate

@michmoor this is interesting:

it says it was made on Feb. 14.

michmoor

@rcoleman-netgate The interface is new. I suspect the copied rules (block RFC1918 and permit !RFC1918) were copied over to this new interface.
It seems that in this particular case, the tracking ID was copied over as well.Its the only thing that would make sense in having a duplicate tracking ID.
I just tested to see if i can duplicate it and i cannot.

stephenw10

Mmm, that should not happen. That's in 2.6? When that rule was created it would not have been though.

michmoor

@stephenw10 I agree steve that this condition should not happen. I gave my best theory and i tested but cant reproduce. Sucks it took me a week to even notice it so i couldve provided accurate steps to what i did but generally if im spinning up a new interface and the access rules are similar i copy the rules from another interface nstead of manually creating the rules from scratch.
Im on 22.05 when i copied the rules, Correct i was on 22.x previously

stephenw10

Hmm, one thing that can appear like that is if you're looking at old logs and have since updated the ruleset. The rule number to rule description is created when the logs are viewed and that can change. So if you added the pass rule after the block rule or deleted another rule at some point the rule description might show incorrectly. Actual running rule numbers should still be different though.

johnpoz

@stephenw10 said in Confused about rule:

The rule number to rule description is created when the logs are viewed and that can change.

Yeah I was thinking the same thing at first - but then he showed his actual rules and the IDs were the same - very strange.