Invert match doesn't work
-
Then what is the point of the inverted rules Derelict?
It should work, there is something odd with his system why its not.
And its not blocking traffic with an allow… Is a specific allow, the block happens with the default deny at the end..
-
Then what is the point of the inverted rules Derelict?
It should work, there is something odd with his system why its not.
And its not blocking traffic with an allow… Is a specific allow, the block happens with the default deny at the end..
Why are they there? That's a really good question.
You have seen what pf does with that kind of rule in certain cases in that filed bug. I am not going to explain it again.
If you want to block traffic, then BLOCK IT!
He makes a rule with a pass ! net. It doesn't work. Does the same thing with a block then pass rule. It works… Again. And will. In ALL CASES!
People are just plain lazy.
OP, just PM the contents of /tmp/rules.debug and I'll tell you why it's not working. That is, a copy of the rule set with the broken invert match rule, not with the (arguably-proper) rule set that isn't broken.
-
Then what is the point of the inverted rules Derelict?
It should work, there is something odd with his system why its not.
And its not blocking traffic with an allow… Is a specific allow, the block happens with the default deny at the end..
@johnpoz I am still looking for the what and why on this inverted rule, as @Derelict has an explanation for it, I first await his answer before posting the file you suggested, I hope this doesn't offend you.
-
rules WLAN
 -
Did you send him the rules? in a PM?
Don't get me wrong, me and Derelict go round and round this topic all the time ;) And there has been bug reports filed, etc. If you have a vip in a different network you can have some weirdness for example.
And I do understand his point about explicit blocking.. But this method of saying you can go everywhere but here is also valid rule syntax.. It is an explicit allow… Allow rules are also suppose to function..
Blocking all traffic that is not allowed is valid way to run a firewall.. You should not have to do a explicit deny when the default deny should cover you, etc.
So yes I am very interested in why in your setup it is not working as it should.
The one thing everyone should always remember is to actually validate a rule set before assuming it will function how you think it will.. To catch something that isn't obvious to the human eye.
-
Did you send him the rules? in a PM?
Don't get me wrong, me and Derelict go round and round this topic all the time ;) And there has been bug reports filed, etc. If you have a vip in a different network you can have some weirdness for example.
And I do understand his point about explicit blocking.. But this method of saying you can go everywhere but here is also valid rule syntax.. It is an explicit allow… Allow rules are also suppose to function..
Blocking all traffic that is not allowed is valid way to run a firewall.. You should not have to do a explicit deny when the default deny should cover you, etc.
So yes I am very interested in why in your setup it is not working as it should.
The one thing everyone should always remember is to actually validate a rule set before assuming it will function how you think it will.. To catch something that isn't obvious to the human eye.
Good to know I send him the the rules.debug and hope to get an answer.
-
Did you send him the rules? in a PM?
The rules I have posted in Reply #44, are because I cannot PM files/pictures (or at least I couldn't accomplish it), so I posted it in this thread.
-
Yup:
pass in quick on $WLAN inet from 192.168.5.0/24 to { !192.168.1.0/24 !10.10.10.1/32 } tracker 1522220684 keep state label "USER_RULE: WLAN -> !LAN"
What is that 10.10.10.1 VIP? DNSBL?
It is not a block rule so quick is not triggered.
Don't try to block traffic with pass rules.
Complete explanation is here:
https://redmine.pfsense.org/issues/6799
-
Yup:
pass in quick on $WLAN inet from 192.168.5.0/24 to { !192.168.1.0/24 !10.10.10.1/32 } tracker 1522220684 keep state label "USER_RULE: WLAN -> !LAN"
What is that 10.10.10.1 VIP? DNSBL?
It is not a block rule so quick is not triggered.
Don't try to block traffic with pass rules.
Complete explanation is here:
https://redmine.pfsense.org/issues/6799
Yes, I've got a Virtual IP and yes it's DNSBL, @Derelict a big thanks for taken the time to explain this to me. A router/firewall that doesn't behave as it should, evokes a unreliable feeling and as always it helps if you know what your doing ;).
Am I right, when I assume that everyone that uses pfBlockerNG, well to be more precise everyone that uses DNSBL or anyone that uses VIP's can't use the inverted rules and should instead use 2 rules; in my case the block to RFC1918 and then a pass to any rule. Shouldn't there be a general warning, when using VIP's, for such behavior? As I look to https://redmine.pfsense.org/issues/6799 this explanation could it be that if the VIP were on a "physical" different interface then this behavior can be isolated to that interface? I use intel NIC's, so if the VIP was on igb0 and everything else on igb1 it would be isolated?
Not to knock on open doors, but is @BBcan177 aware?
….networking is hard ;)
-
Pretty sure I brought up VIPs in like page 1 of this thread..
Yeah I Have brought it up multiple times ;) Looking back over the thread.. I should of recalled that pfblocker does that nonsense with 10.10.10 which is broken!! Since amounts to using multiple layer 3 on the same layer 2.
-
Pretty sure I brought up VIPs in like page 1 of this thread..
Yeah I Have brought it up multiple times ;) Looking back over the thread.. I should of recalled that pfblocker does that nonsense with 10.10.10 which is broken!! Since amounts to using multiple layer 3 on the same layer 2.
Yep, you're right in reply #7 you' already suggested a VIP being the culprit, thanks @johnpoz
-
I mentioned to BBcan177 that Localhost should be an option (the default, probably) for this VIP when I opened that bug report.
It is not a bug in pfBlockerNG. It is not really a bug in pfSense. But both could probably do better here.
Don't block traffic with pass rules. If you want to block it, block it.
-
heheheh - this is where we are going to disagree Derelict.. A ! dest is not a block with a pass rule. It is a specific pass. It is not really any different than say you can can pass if your dest is 1.1.1.0/24..
It really like a any rule… Which everyone is fine with..
With your logic really the only pass rule should be any and everything should just be blocked ;)
-
Except with the way pf deals with those. Quick isn't triggered. It would be if it was an explicit block rule.
If you want to block traffic, effing BLOCK it. This simple principle will keep you out of the weeds.
