VLAN Handling¶

Current status¶

We only peel off the vlan layer. We decode it, decode the next layer. But as we effectively ignore the vlans, we risk mixing up traffic from 2 or more vlans.

Adding support¶

Step 1: flow¶

By taking vlan id into account in the flow hash, we'll be able to separate flows from different vlans.

2 layers of vlan should be supported. With more, events should be set.

https://redmine.openinfosecfoundation.org/issues/813

A global switch to disable this behavior should be added as it has been documented that some ppl run broken vlan setups that can't be fixed easily. This global switch should probably be enforced in the vlan decoding layer, by not adding the vlan id's to the packet. This way we don't need to add conditionals to the flow code.

Step 2: defrag¶

Defrag suffers the same problem as flow. We track a 'ssn' by src ip, dst ip and frag id, but it's possible to mix up frags from several vlans.

The defrag hash is structured like the flow hash, so we can just take the vlan id(s) into account.

Step 3: host¶

With hosts something interesting happens. In 2 vlans, 192.168.1.1 will likely not mean the same. However, 1.2.3.4 will. So we should ignore vlan for publicly routable ip's probably. For local networks, things are less clear. Maybe we should make it fully configurable.

Further complication here is that thresholding uses this host table, but so does ip rep. IP rep is normally used for reputation of public IP's, but if ppl would want to use it for private ip's this needs to be considered.

Step 4: rules¶

We need to be able to select vlan in rules through vars like HOME_NET.