Confused about rule

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.