Handling of VLAN tagged packets

[aldem]

It would be nice to incorporate VLAN tag support into the rules (and maybe maps too).

Currently, the firewall processes only untagged packets. In environments where an interface handles multiple VLANs, this limitation causes the firewall to overlook tagged packets.

While it is technically possible to attach directly to a VLAN interface - albeit with the performance penalty of SKB processing - a more efficient solution would be to manage VLAN tagging at the entry point, thereby reducing overhead.

For example, consider a router equipped with a high-speed interface (10Gb or 40Gb) that carries numerous VLANs. Implementing VLAN support within the firewall would allow us to manage all VLANs by attaching to a single interface instead of requiring separate attachments for each VLAN, while avoiding the SKB processing overhead.

[gamemann]

Hey, thank you for the suggestion! I will look into this when I have the time.

I believe using an additional offset when initializing the IP and layer 4 header pointers that is the size of the VLAN header should be enough.

[tt2468]

I believe using an additional offset when initializing the IP and layer 4 header pointers that is the size of the VLAN header should be enough.

I'm not super advanced in my understanding of XDP, however wouldn't this still mean that, in the best case, some extra instructions are executed, and in the worst case, some traffic is unintentionally dropped? As you would be filtering packets on all VLAN traffic, rather than just a specific VLAN.

[aldem]

Actually, once we enter VLAN territory, it makes sense to make the VLAN ID part of a rule; otherwise, we could indeed have issues if different VLANs have overlapping IP ranges.

As for "extra instructions" — everything has a price, but in this particular case the price is very low.