Fortigate vendor detected application data garbled characters

Is there some sort of character encoding issue with the Fortigate application data? Is there a way to fix or normalize the data on the Elastiflow flow collector?
Running Elastiflow NetObserv 7.4 and FortiOS 7.4.4

I have not seen that reported by anyone else and it looks more like a browser issue than a data-collection issue. Are you seeing it only with Fortigate? Can you try with another browser? Which browser are you using? Does it have any special encoding set? Can you clear cache and retry?

I know we have many people collecting flow from fortinet gear. If it’s not browser related we would need a packet capture to investigate further.

You might try looking at the data using Dev Tools … maybe query something like:

GET .ds-elastiflow-flow-ecs-8.0-2.4-tsds-2024.11.03-000006/_search
{
  "_source": ["app.descr"],
  "query": {
    "match_phrase_prefix": {
      "app.descr": "Microsoft.Portal"
    }
  },
  "size": 10
}

… which should show you the text stored and give a clue about where the special characters start and maybe why.

Would the JSON output be equivalent?

What’s the best way to check what Elastiflow is receiving from Fortigate? I took some packet captures but couldn’t find the corresponding data in Wireshark. Maybe I’m not looking through a large enough Netflow data set?

The PCAP is the best way to see what is received. In Wireshark you’ll need to select a packet, right click, and choose ‘Decode as’ either CFLOW or IPFIX depending on the Netflow version.

Based on the above it certainly seems like the device is sending data with a different encoding. Would be good to see the PCAP information.

Also, FYI, actual text is easier to troubleshoot with than screen shots. I usually just copy the text and format it in the comment with the "code ... </>" format.

It looks like the data is coming from Fortigate in that format. Is the data below following Netflow specs or is it an issue I need to raise with the vendor?

APPLICATION_NAME (96, length: 64)

0000   4d 69 63 72 6f 73 6f 66 74 2e 54 65 61 6d 73 5f   Microsoft.Teams_
0010   41 75 64 69 6f 00 00 00 0d 26 e3 1e 5a 26 e3 1e   Audio....&..Z&..
0020   6e d1 c7 05 a4 00 36 00 32 06 00 02 02 14 00 00   n.....6.2.......
0030   30 44 00 00 00 00 00 00 00 00 0c 0c 40 03 c0 a8   0D..........@...

APPLICATION_DESC (94, length: 64)

0000   4d 69 63 72 6f 73 6f 66 74 2e 54 65 61 6d 73 5f   Microsoft.Teams_
0010   41 75 64 69 6f 00 00 00 00 00 00 14 7a 00 00 00   Audio.......z...
0020   0c 00 00 00 0c 26 e3 14 b4 26 e3 1e b4 01 bb e0   .....&...&......
0030   25 00 b0 00 9a 06 14 50 50 14 00 00 30 44 00 00   %......PP...0D..

applicationCategoryName (372, length: 32)

0000   43 6f 6c 6c 61 62 6f 72 61 74 69 6f 6e 00 ac 1e   Collaboration...
0010   66 9e 00 00 00 00 29 47 76 62 00 00 e0 25 00 00   f.....)Gvb...%..

I’m suspecting the latter since Wireshark also seems to be unhappy about the format.

I would certainly ask the vendor about it. I don’t think it’s an encoding thing since we get the first part of the text, but it could be an encryption thing or maybe it’s sending the last bit as binary data?

You might want to look at the templates that the Fortigate is using/sending, too. It could be that the device is using a customized template or something. There should be template packets in your capture,too, that describe what data is being sent.

The template looks okay to me. I’ll reach out to the vendor.