Suricata 6.08 does not include VLAN in an alert despite the VLAN being present in the packet

Help
1

Suricata does not include the VLAN in some alerts despite the VLAN being present in the packets.

I extracted 3 packets from from a larger PCAP file and modified the IP addresses. 2 of the packets’ payload contain a DNS query containing, “google”. See: cleaned.pcap (361 Bytes)

The VLAN is not in the alert in eve.json:

{
  "timestamp": "2023-01-10T21:41:27.594116+0000",
  "flow_id": 489960667287748,
  "event_type": "alert",
  "src_ip": "7.7.7.5",
  "src_port": 13050,
  "dest_ip": "7.7.7.6",
  "dest_port": 53,
  "proto": "UDP",
  "ether": {},
  "tx_id": 0,
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 1000991,
    "rev": 0,
    "signature": "search for google in dns.query",
    "category": "",
    "severity": 3
  },
  "tunnel": {
    "src_ip": "7.7.7.3",
    "src_port": 0,
    "dest_ip": "7.7.7.4",
    "dest_port": 0,
    "proto": "GRE",
    "depth": 1
  },
  "app_proto": "dns",
  "stream": 0,
  "packet_info": {
    "linktype": 12
  },
  "pcap_filename": "/sourcedir/1673577444.0.0.pcap"
}

However, the other alert does contain the VLAN:

{
  "timestamp": "2023-01-10T21:41:31.697025+0000",
  "flow_id": 1290177499341505,
  "pcap_cnt": 3,
  "event_type": "alert",
  "vlan": [
    1017
  ],
  "src_ip": "7.7.7.7",
  "src_port": 25939,
  "dest_ip": "7.7.7.8",
  "dest_port": 53,
  "proto": "UDP",
  "ether": {
    "src_mac": "00:24:dc:c6:6c:ac",
    "dest_mac": "00:90:69:fe:00:80"
  },
  "tx_id": 0,
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 1000991,
    "rev": 0,
    "signature": "search for google in dns.query",
    "category": "",
    "severity": 3
  },
  "app_proto": "dns",
  "stream": 0,
  "packet_info": {
    "linktype": 1
  },
  "pcap_filename": "/sourcedir/1673577444.0.0.pcap"
}

I’m unsure if I am misunderstanding configuration or if there’s another issue. Any guidance on what I ought to try to get Suricata to list the VLAN?

Let me know if I should provide more information. Thanks and I appreciate any help!

2

I would guess it’s related to the inner GRE tunnel. Normally I would expect the GRE tunnel outside and the VLAN within. So might be up for a discussion if this is valid and if the vlan tag should still be extracted. So could be a bug or intentional behavior.

3

Hey Andreas, what should be my next steps? I do need Suricata to populate the VLAN if it exists. Should I submit a bug report for this and/or try and look at the source code myself?

The original packets are from real traffic (though I anonymized the IP addresses and took out the specific packets where I noticed the problem).

4

Feel free to open a redmine ticket for that, we can decide if it’s a bug or a feature. Ideally you can provide a RFC or other docs that proves that this is valid. The reason is, that sometimes real traffic is not following RFC adn thus it’s up for discussion if it should even be supported.
I just have never seen VLAN > GRE only GRE > VLAN (including the VLAN in it on the actual traffic), but might be valid so should be supported or at least looked at.

If you feel confident, a code submission is welcomed as well.

5

From what I see, the RFCs for GRE (RFC1701, RFC1702, and RFC2784) do not place any constraints on the delivery protocol. RFC1720, in fact, refers to the delivery protocol as “arbitrary”. So if IPv4 can be used as the delivery protocol and IPv4 supports VLANs, then it seems that we should expect that VLANs may appear in the delivery header.