Firewall info (one year or more later) and possible improvement

[Jan Janowski]

No VLAN here, due to the amount of TP self created Rules created YEARS AGO.... These All would Need IP editing if a VLAN was used)...A year or so ago (Probably longer), I added a bunch of firewall rules to break out the "HITS" so more explicitly explain where the "Hits" are coming from....
At that time I also created rules for ICMP (PINGS), too... This was augmented by creating and using a: BOGUS GATEWAY, for devices I don't want to ever access internet, and followed up with Router Firewall Rules tto verify that devices using "Bogus Gateway" did not try to use "Real Gateway" later!!!

One year later, I am more or less happy with the Rules I created, but the HITS are kind of vague...as there are some Un-Known hits from IP's..... and less ICMP rules than TCP/UDP rules getting hits... So If an issue came up with a device going rouge or such, It would be hard to determine which device was acting up.... That is the basis of this.... Nothing acting up now, but wanting to make it easier to determine if a device went rouge in the future!!!!

I'm thinking it would be easier to determine ICMP than TCP/UDP, so I'm starting there.. ICMP, as it will cause less issues if I do something stupid...

For example, today I see 82 Pings HITS, from devices that are NOT Security cameras, nor Computers, or NAS’s…. on my BLOCK ALL IP's with ICMP...
Due to the way I've separated my IP Groups years ago, I see his will cause more rules than I hoped for.... to cover the 256 devices that could be on my LAN...

Obviously, I should 'start over' with new ranges for all devices on the LAN, to simplify the IP range's being used, but that puts me back where I was with VLAN in that I have hundreds of TP Self Created rules I'd have to edit... So AGAIN I'm leaving the EXISTING IP's alone.... and continuing on with multiple Firewall ICMP Rules....

My original idea for revised ICMP Rules were 11 rules, but got it down to 3 plus the existing 3 ICMP rules...
Turns out my existing TCP/UDP allow rules had done about 90% of this already, but under vaguely named rules over the years... Updated Rule names to more aptly explain what's going on it them! I could add a few more to break the HITs down to more specific devices... So I did. That's What I get for creating firewall rules with vague names over a 5+ year time frame!! This made things clearer, too.

What this will result in: The ICMP DENY ALL rule should go to ZERO HITS, and the TCP/UDP Allow rules will break out Hits to a more explain-able list.... Making subsequent troubleshooting (should a device start acting bad, in the future)..... Easier to spot!
ICMP Deny and Allow rules are now finished.... TCP/UDP Allow Rules are finished. Deny breakout is mostly done, but is covered by the DENY ALL rule at bottom of firewall list. And my Firewall Rules have been Renamed in a way to make them clearer in name as to what they are doing!

Would have liked to do his on FIrewall on NAS's too... but not seeing "HITS" makes it hard to create specific rules, even if you wanted to!!! This also makes rules created that should NEVER see a HIT impossible - on NAS's.... Oh! How I wish NAS's Firewall Had HITS!!!!

 

[Jan Janowski]

Question about Firewall rules, HITS, and the famous DENY ALL Rule used at the bottom of Firewall Rule List....

Now if I have enough rules such that: NO VLAN... Subnet is: 255.255.255.0
1. With ICMP Allow rules of specific IP's getting HITS and The ICMP DENY ALL rule below them pointing at: 192.168.12.0/255.255.255.0 Gets NO HITS...
and...
2. The TCP/UDP Allow rules of specific IP's getting HITS, and TCP/UDP DENY ALL rule below them pointing at: 192.168.12.0/255.255.255.0 Gets NO HITS.....

WHY IS IT THAT the DENY ALL Rule: (TCP/UDP ALL ALL ALL ALL ALL ALL DENY) AT BOTTOM OF FIREWALL RULE LIST - STILL GETTING HITS?

I would have expected No Hits from the DENY ALL rule at the bottom of Firwall list.... What am I mis-interpreting?

 

[Jan Janowski]

More questions....
if the firewall rule is:
TCP/UDP ALL (either 192.168.12.0-192.168.12.255 OR: 192.168.12.0/255.255.255.0) ALL ALL ALL ALL DENY --- THE RULE GETS NO HITS.
BUT:
IF I ADD THE FOLLOWING RULE BELOW THE 2 JUST MENTIONED -- THIS BOTTOM RULE IS: TCP/UDP ALL ALL ALL ALL ALL ALL DENY THIIS RULE GETS HITS!!!

SO AM I SEEING EXTERNAL IP'S BEING BLOCKED? OR ___________? What is it trying to tell me?

I don't seem to be having any issues, I just never tried these rules above one another.... in the list....

Thanks in advance for the education...

 

[fredbert]

It's not really clear to me but sounds like the two pairs of rules (ICMP and TCP/UDP pairs) both could have gaps in the whole of IPv4 source to whole of IPv4 destination. That these gaps are then being caught by the all/all deny rules.

Remembering that the firewall rules are tested from the first rule at the top to last at the bottom. When a rule's parameters are matched then the action is performed and no lower rules are tested. All parameters must match, not some, all: source interface, IP address, and port; destination interface, IP address, and port.

 

[Jan Janowski]

Agreed: Firewall rules executed top to bottom:

But if in the middle: there are 2 rules: ICMP deny ALL on LAN Range followed lower by TCP/UDP Deny ALL on LAN Range, and both gets NO HITS...
and at next to botton is a rule: TCP/UDP ALL LAN RANGE ALL ALL ALL ALL ALL DENY ---- Getting NO HITS...

and the bottom Rule: TCP?UDP ALL ALL ALL ALL ALL ALL DENY and THIS GETS HITS..... WHERE ARE HITS COMING FROM??

I'll post a screen capture pix in a while.....

 

[Jan Janowski]

here is what bottom lines of firewall rules looks like Live Capture Again: NO VLAN here. No Guest WIFI. IPV6 is disabled.
Latest SRM 1.3.2 Latest TP, Latest SA...
If the HITS are not coming from LAN.... WHERE? I have never looked a the rules this way before... I am NOT having any issues... Everything tests clean... Just confused on what it's trying to tell me! I'm off to pick up parts for mower....
Thanks for your comments...

 

[fredbert]

It can only be that the firewall is matching on DENY ALL OTHERS because the source IP addresses falls outside the 192.168.12.0/24 subnet. There's no other reason for it. But if you think that the source IP should be within 192.168.12.0/24 then:

• Check the client/source devices actually have a 192.168.12.0/24 IP address, and
• Check that there isn't a router in the way that is NAT'ing the source IP address behind its external IP address (the one it is using to send on the packets).

 

[Jan Janowski]

A Bot from Synology replied to my request.... #3 is the important part
Actually I'm impressed that a BOT could be so helpful... If it hadn't said it was a BOT Replying, I'd have never known it... Printing out reply as a reference!!!

This explains what I’m seeing.

Based on your description and screenshot, your firewall is operating correctly and as intended. The behavior you are observing is a sign of a secure firewall configuration. Here is a breakdown of why you are seeing these hits:

1. Firewall Rule Processing: Firewall rules are processed in order from top to bottom. When network traffic attempts to pass through the router, it is checked against your rules one by one. The very first rule that matches the traffic is applied, and no further rules in the list are checked for that specific connection.
2. The 'DENY ALL OTHERS' Rule: This rule, placed at the end of your list, acts as a crucial 'catch-all'. Its purpose is to block any and all traffic that has not been explicitly allowed or denied by a rule positioned above it. The hits you see are a count of all the connection attempts that did not match any of your other rules.
3. Source of the Hits: The traffic being blocked by this final rule is typically unsolicited inbound traffic from the internet. This is very common and includes:
   • Automated bots and scanners looking for open ports on your network.
   • General internet background 'noise' and random connection attempts.
   • Any other traffic trying to reach your network that you have not specifically permitted through a port forwarding or other 'Allow' rule.
4. Zero Hits on Other Rules: Your other 'Deny' rules have zero hits simply because no traffic has yet met their specific criteria. If traffic matching one of those rules were to appear, its hit counter would increase, and the traffic would be blocked before ever reaching your final 'DENY ALL OTHERS' rule.

I’m leaving both the TCPIDP DENYALL rule & DENY ALL OTHERS rule. Another instance where an old dog learns a new trick!

 

[fredbert]

Fair enough, But I think I already said all that.

Maybe I didn't pick up that 192.168.12.0/24 is the only internal subnet, there could be a second router set up as an access point that this subnet is connected. I saw the GL.iNet implementation of access point mode still uses a separate IP subnet for connecting devices... it's more like a connected router with open firewall policy. I try not to make assumptions.

 

[Jan Janowski]

Do have 2 other routers on LAN. (Neither Synology):

One is in garage, wired, at .20, And is a 5Ghz WIFI access point, with nothing connected to WAN. No DHCP Access, further limited to: only Static IP phones. It does double duty as GB Switch for workshop in Attic. Garage is far enough from house that there is seamless automagic connections as you walk between the two buildings. This in use here for nearly as long as I’ve had 2600 as main router, and pre-dates 2600 mesh. It was previous WIFI router. So successful, I never tried mesh.

Other wired router is at .1, And is our “Bogus Gateway” (Nothing connected to WAN) Used for Security cameras and others: any device that we don’t want to have access to Internet. Our: “Gateway to NO-WHERE”! Without it, all devices were flooding LAN with: “Whereis x.x.x.1?” Traffic. This is our work around to avoid VLAN & having to edit IP in hundreds of TP Custom rules, that pre-date VLAN in 2600.
Both: though each are way old, do their jobs successfully, didn’t cost anything to implement, and ‘hide behind’ 2600/Firewall/TP/SA.