Firewall Invert Match doesn't work?
-
Am I wrong that the invert match doesn't work here?
I would think the blocked traffic should show up in the logs as from the first rule, but seems it does nothing and hits the second rule. I guess I could imagine when using "invert" option that maybe it purposefully is not logging, but if that were the case why would the traffic continue to be evaluated and be matched by the second rule?
pics attached (easier to explain flows)
) -
@lpfw said in Firewall Invert Match doesn't work?:
Am I wrong that the invert match doesn't work here?
I would think the blocked traffic should show up in the logs as from the first rule, but seems it does nothing and hits the second rule. I guess I could imagine when using "invert" option that maybe it purposefully is not logging, but if that were the case why would the traffic continue to be evaluated and be matched by the second rule?Since you've checked "invert match" and stated the alias, which includes your destination IP, the pass rule does not match, naturally. This way you excluded your destination IP from the rule.
Consequently the next matching rule is applied to the traffic.
BTW: 168.108.108.0/24 is your LAN subnet?
Are you aware of using a public IP? -
oooooh...! Thanks! Makes sense now :)
Yep re: using public IPs
Should be fine. Not running a routing protocol w/ISP and everything is Src Nat'd so technically doesn't matter.
-
@lpfw Might not matter now but what if Googles address was 168.108.108.45?? Think you'll ever get there?
What if any public site you want to reach uses an address in that range, think you'll ever get there?
Why would a packet destined for an address on your LAN ever reach the WAN? -