IGMP = UDP (or TCP) on port 8443 - how is that?

Started by lar.hed, December 23, 2023, 06:31:15 PM

Previous topic - Next topic
December 23, 2023, 06:31:15 PM Last Edit: December 23, 2023, 07:19:46 PM by lar.hed
So this is most likely a beginner question, I will ask it anyway...

I have set up "counters" as I call them, this is filters that only purpose is to yes count +1 for each time it matches. So I have IGMP setup and then 8443....... Se the attached picture, we can see that only one of 7 lines are in the filter for IGMP - rest is classed as port 8443(udp) - how is this even possible if the proto is IGMP in the first place?

Yes the Counter 8443 is with (Global) Gateway selected (failover from WAN to LTE) - IGMP counter has no Gateway selected. Yes the 8443 rule is before the IGMP counter rule. So how is this possible? What am I missing?

I don't get the "issue"? IGMP rule obviously does not match UDP. Set the protocol to any if you want to "counter" all traffic.

Maybe not an issue in the first place, however why does a rule that is marked for example protoname = tcp end up with filtering IGMP packets?

I have attached a few things here:
- One more screenshot from LiveView that shows that different packets are handled by different rules, although all are IGMP packets (sorted by LiveView filter protoname = IGMP). There are some markers added by me...
- One detail view of such a packet (dark green marking).
- The corresponding filter on the dark green packet above.

Issue? Maybe not - but from my perspective this should not happen, or rather the IGMP rule should collect them all? and not UDP/TCP at all? That is the question....



IGMP works directly on top of the Internet Protocol (IP). Each IGMP packet has both an IGMP header and an IP header. Just like ICMP, IGMP does not use a transport layer protocol such as TCP or UDP.

from: https://www.cloudflare.com/learning/network-layer/what-is-igmp/


IGMP is not UDP. All addresses shown are multicast addresses and as you see in your picture the IGMP uses 224.0.0

Good I learned a few bits then - still don't understand why the filter mechanism catches on the TCP 8443 filter though....


In reply #4 above the rule for 8443 is shown, and here is the IGMP filter attached.

The 8443 rule is before the IGMP rule.

There is something really strange going on here....

And I do not expect to be believed but: either Firewall-Log_Live View is showing the wrong rule for every package, or the wrong rule is applied on each and every package.

So background is at part above, however this got to be something else.

I added a filter "counter on all ICMP protoname packages" and then all of a sudden, under live view, filtered for protoname=IGMP, I get the ICMP counter. The ICMP rules is AFTER my IGMP rule. So why on earth is not the IGMP rule executed? Well I guess it maps wrong somewhere (I hope at least). So I move the IGMP rule to the top of my filters - yes that got IGMP counter on all packages. I then move my ICMP rule to just after the IGMP rule, and now all IGMP packages are market as "Counter ICMP". Now the ICMP rule is AFTER the IGMP rule... I then add a 224.0.0.0/4 rule above all for "Counter Multicast" and well that one grabs all rows. So I move the ICMP rule to between the 224.0.0.0/4 rule and IGMP rule - anyone can guess what Live view now shows on all packages in Live View where protoname=IGMP? Yes exactly, they now all show ICMP rule...

Might add two things:
The interface, ALL_LAN, is a group of the interfaces that are on the intranet side, which "shares" some of the rules needed.
I am also running IGMP proxy between all interfaces for ALL_LAN.

I do not expect any of the above to be the reason, however it could very well be good to know.

And yes, I am confused - however since it is Christmas Day:

Merry Christmas to each and everyone !!!!

QuoteSo I move the ICMP rule to between the 224.0.0.0/4 rule and IGMP rule - anyone can guess what Live view now shows on all packages in Live View where protoname=IGMP? Yes exactly, they now all show ICMP rule...
this can be a temporary effect if monitoring and changes are carried out in parallel (say, live log is opened in one tab, and in another you change the order of the rules): the rule number changes, but the log parser may not yet know about it. just ignore the entries BEFORE changing or work in one tab and use templates

Sorry to say, but how/when I watch in LiveView does not matter - the error is still there.