Duplicate tracking ID

michmoor

I am aware of the duplicate tracking ID bug that's seen and have experienced it myself. Typically i just look for the rule in pf and re-create it so it can have a new tracking number but i need help in figuring out which rule this is supposed to be linked to.

/root: pfctl -vvsr | grep 1000002520
@34 block drop in log on ! igc0 inet from 192.168.50.0/24 to any ridentifier 1000002520
@35 block drop in log inet from 192.168.50.254 to any ridentifier 1000002520
@36 block drop in log inet from 192.168.50.100 to any ridentifier 1000002520
@37 block drop in log on igc0 inet6 from fe80::92ec:77ff:fe34:cedc to any ridentifier 1000002520
@38 block drop in log on igc0 inet6 from fe80::1:1 to any ridentifier 1000002520

Bob.Dig

@michmoor Here are some helpful tips. I did it with the config.xml.

michmoor

@bob-dig @stephenw10
Appreciate the assist. Seems we got a problem. That ruleID doesnt show up.

[22.05-RELEASE][admin@GA-FW1]/conf: cat config.xml | grep 1000002520
[22.05-RELEASE][admin@GA-FW1]/conf: date
Wed Jan  4 16:25:12 EST 2023
[22.05-RELEASE][admin@GA-FW1]/conf:

Yet that rule is being hit somehow, somewhere

Bob.Dig

@michmoor At least you know the interface. With that information, cant you do a visual inspection? Probably a floating or group rule. Otherwise it must be in every space.

stephenw10

Those are not user rules so they won't be in the config. They look more like the antispoof rules. Look at the ruleset in /tmp/rules.debug.

stephenw10

Yes the logs look like you have traffic coming in from the igc0 subnet on other interfaces because something is leaking multicast traffic between them. Probably a switch. Unifi?

michmoor

@stephenw10 Help me understand why igc0 or igc1 comes up in the logs but its called 'LAN' in the or IOT in the config. Why is it using the physical name of the interface instead of the description?
Yes there is a unif switch in the mix. I also see other hosts on the LAN network that are not Unifi hitting this rule.

@34 block drop in log on ! igc0 inet from 192.168.50.0/24 to any ridentifier 1000002520
  [ Evaluations: 410862    Packets: 2854      Bytes: 461405      States: 0     ]
  [ Inserted: uid 0 pid 31615 State Creations: 0     ]
  [ Last Active Time: Thu Jan  5 15:07:53 2023 ]
@35 block drop in log inet from 192.168.50.254 to any ridentifier 1000002520
  [ Evaluations: 410692    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 31615 State Creations: 0     ]
  [ Last Active Time: N/A ]
@36 block drop in log inet from 192.168.50.100 to any ridentifier 1000002520
  [ Evaluations: 410560    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 31615 State Creations: 0     ]
  [ Last Active Time: N/A ]
@37 block drop in log on igc0 inet6 from fe80::92ec:77ff:fe34:cedc to any ridentifier 1000002520
  [ Evaluations: 1439874   Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 31615 State Creations: 0     ]
  [ Last Active Time: N/A ]
@38 block drop in log on igc0 inet6 from fe80::1:1 to any ridentifier 1000002520
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 31615 State Creations: 0     ]
  [ Last Active Time: N/A ]

Bob.Dig

@stephenw10 said in Duplicate tracking ID:

They look more like the antispoof rules. Look at the ruleset in /tmp/rules.debug.

In other words, there is no duplicated rule there in the first place?

stephenw10

@michmoor said in Duplicate tracking ID:

Help me understand why igc0 or igc1 comes up in the logs but its called 'LAN' in the or IOT in the config. Why is it using the physical name of the interface instead of the description?

Maybe because you don't have igc1 assigned as an interface dircetly? Only VLANs on it?
Because the rule is for 'not igc0' that includes all interfaces that pf can see including untagged on igc1. The switch is leaking it there.

I still would not expect the same rules ID there though.