Odd block drop in log on rules with new Rules GUI and deleted LAN

[cat]

Trying to figure out why a PC on an undesired vlan (vlan not allowed access to opnsense) is able to reach opnsene.
Went through a couple of changes today on the opnsense and one of them was to switch to the new rules which went fine without complaints.
I realized during the process that the undesired vlan was now on anti-lockout, something that happened before today's modifications but i didn't see it back then when i removed the LAN interface. Anyways WAN access is disabled and disabled anti-lockout.
Unfortunately this undesired vlan remains having access to the GUI/ssh.

Running
pfctl -sr | grep -i vlan01
block drop in log on ! vlan014 inet from ... to any
block drop in log on ! vlan015 inet from ... to any
block drop in log on ! vlan013 inet from ... to any
block drop in log on ! vlan01 inet from ... to any

I can no where in the GUI find the reason why the first three lines vlan014,vlan015,vlan013 show up here. All other vlan only have one block drop line for it's own vlan but vlan01 has also pass in quick and pass in log rules for the vlans listed above including a pppoe0 connection line for the vlan014.

I'll try a backup tomorrow but i fear deleting the LAN interface killed my setup which was running fine for years.

[pfry]

Those are (almost certainly) basic anti-spoofing rules, if you look closely at them. Defaults. The only time I hit them was when I had the main (untagged) interface configured as well as VLANs (on the same interface), where VLAN-tagged traffic was improperly captured by the main. A possibility?

[cat]

Good Morning, thanks for the reply.

I upgraded my switch couple of weeks ago and iirc igc0 used to be the trunk (i believe on LAN), that was connecting to the previous switch but is now used for pppoe. Unfortunately i deleted all the previous config backups so i cannot be 100% certain. I am now using lag/lacp.

I also realized that this three extra rules all point to vlans that were created after the deletion and switch upgrade.

[pfry]

Hm... Their presence would suggest configured interfaces. If you had deleted them, that's an interesting data point. I haven't personally seen OPNsense fail to clean up something like that. Something to watch for.

[OPNenthu]

In playing with an instance of 26.1 in a VM recently, I noticed that if you just delete an interface using the trash icon in Interfaces->Assignments to unassign it then the rules do not get deleted.  The configuration identifier (e.g. optX) gets recycled and the next interface you assign which inherits it will also inherit the old interface's rules.

Or something like that, it was confusing. What I do remember is that rules got reassigned somehow rather than getting deleted.  The references to interface names within the rules (e.g. src/dest) got replaced with 'optX' identifiers.

Take away: if you truly want to remove an interface, it's a good idea to manually delete its rules first then delete the interface.  Or, clean up the config file manually.

If you're changing VLAN assignments, which is what I was doing, this can get messy.