[netsa-tools-discuss] SiLK not accepting Cisco FTD/ASA flows

[Mark Thomas]

Difan-

Hello. I apologize for the delay in responding.

Thank you for providing your configuration files. Collection worked for me when I used your configuration files and replayed the pcap file you had previously supplied. I do not know why the collection is working for me but not for you.

To check whether rwflowpack is the issue: I would expect the rwflowpack log file to contain messages like

'probe_rogersPrdFw': forward 14218, reverse 5935, ignored 80729, nf9: missing-pkts 0

every --flush-timeout seconds. If you are not seeing that, then the problem is with rwflowpack.

Things to check are

  *   that rwflowpack is using the configuration files you expect it to be using
  *   that you restarted rwflowpack after modifying the files
  *   that another process is not listening on the same port, as that situation is not fatal in libfixbuf and yet it would prevent rwflowpack from being able to collect the data on that port

If you do see the above log messages, check that rwfilter is reading the files from the directory where rwflowpack is writing them. Compare the paths printed in the rwflowpack log, such as

/tmp/silk/data/int2int/2025/07/15/int2int-rogersPrdFw_20250715.21: 11868 recs

with the paths that rwfilter prints when you use the --print-missing-files option.

I hope that helps.

-Mark


On Jul 16, 2025, at 19:34, Difan Zhao <difzhao at suncor.com> wrote:

Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe.


Restricted

Hi Mark,

Thank you very much for your quick response. SiLK has been an excellent tool for us, and we truly appreciate all the hard work you and your team have put into it.

I will look into rebuilding libfixbuf as you suggested. However, I wanted to clarify that the log messages are not the only reason I mentioned not seeing any data—the main issue is that there are no files being created in the data directory, and rwfilter is also unable to find any data.

[t1.difzhao at network.lan<mailto:t1.difzhao at network.lan>@grfprd003z SiLK]$ rwfilter \
  --site-config-file=/Data/SiLK/silk.conf \
  --data-rootdir /Data/SiLK/rwflowpack/output/ \
  --type=all \
  --sensor=rogersPrdFw \
  --start-date=2025/07/17:00 --end-date=2025/07/17:23 \
  --all-destination=stdout | \
  rwcount
               Date|        Records|               Bytes|          Packets|

I’m very interested to know why it works on your end. For your reference, I’ve attached the complete configuration files. Additionally, I just noticed that when the FTD/ASA flow is enabled, it seems to “kill” the other flow source from our Cisco router (referred to as netflow1cisco in the sensor config). I’m not sure if this is a coincidence or if the issues are related.

Thank you again for taking the time to look into this for me.

Best regards,
Difan

From: Mark Thomas <mthomas at cert.org<mailto:mthomas at cert.org>>
Sent: Wednesday, July 16, 2025 2:15 PM
To: Difan Zhao <difzhao at suncor.com<mailto:difzhao at suncor.com>>
Cc: netsa-tools-discuss at cert.org<mailto:netsa-tools-discuss at cert.org>
Subject: Re: [netsa-tools-discuss] SiLK not accepting Cisco FTD/ASA flows

⚠️
EXTERNAL EMAIL WARNING: Do not click links or open attachments unless you expected the email and confirmed it is safe.
AVERTISSEMENT DE COURRIEL EXTERNE: Ne cliquez pas sur des liens ou n'ouvrez pas de pièces jointes à moins que vous attendiez le courriel et ayez confirmé qu'il est sécuritaire.
Difan-

Hello, and Thank You for using SiLK and for your question. I really appreciate you providing the pcap file.

Despite all the noise in the log file, it appears to me that SiLK is reading the NetFlow data correctly. I see SiLK records being produced when I replay the NetFlow packets in the pcap file.

The large number of ignored records are do the notifications that a flow has been initiated. SiLK will record that record once it is closed.

I am sorry the messages in the log file lead you to believe that data was not being collected.

The easiest way to quiet the log file is to set the --log-level to the less verbose setting.

The log messages for "NetFlow V9 sequence number mismatch" are a result of the differences in the way NetFlow v9 and IPFIX manage sequence numbers. Nothing can be done about those.

The log messages for "Template warning: Illegal length" are due to the lack of foresight on our part. Fortunately, you can work-around the issue and quiet that warning if you are willing to rebuild and reinstall libfixbuf, and then rebuild and reinstall SiLK.

SiLK uses the libfixbuf library to process IPFIX and NetFlow V9 data. libfixbuf maps unknown/unsupported NetFlow V9 Cisco information elements to an arbitrary element that we created, ciscoNetflowGeneric. Unfortunately, we created that element as a unsigned64, which has a maximum size of 8. The INGRESS_ACL_ID, EGRESS_ACL_ID, and AAA_USERNAME elements in your pcap file have sizes larger than that, and that is why those messages appear in the log.

In hindsight, we should have created the ciscoNetflowGeneric element as the type octetArray which would support any size. Making that change yourself is not difficult.

To address the issue, download the source file for libfixbuf, expand it (untar it), and change directory into the top of the source tree.  From there change directory to src/infomodel.

Open netflow9.xml in a text editor. Find the definition of the ciscoNetflowGeneric element, and change its type from unsigned64 to octetArray. It should look like this after that change:

|    <record>
|      <name>ciscoNetflowGeneric</name>
|      <dataType>octetArray</dataType>
|      <cert:reversible>false</cert:reversible>
|      <elementId>9999</elementId>
|      ....

In that same directory, rename the netflowv9.i file to netflowv9.i.old. The netflowv9.i file is created from netflowv9.xmlusing the xsltproc command, so ensure you have the xsltproc command available on your system.

Change directory back to the top of the libfixbuf sources. Rebuild and reinstall libfixbuf using the familiar "make && make install" sequence.

Now you can rebuild and reinstall SiLK.

When you restart rwflowpack, you should discover that the illegal length warnings no longer appear.

I hope that quiets the log file for you.

Thanks again for using SiLK.

Cheers,

-Mark



On Jul 16, 2025, at 13:18, Difan Zhao <difzhao at suncor.com<mailto:difzhao at suncor.com>> wrote:



Restricted


Hi team,

My name is Difan, and I am currently setting up a Netflow server for my company. My background is in networking, so please forgive me if I ask any basic questions.

The system is up and running, and it works well with our Cisco and Juniper routers and switches. However, I am having trouble getting the Cisco FTD Firewall to work. (Cisco FTD is the newer version of the ASA.) I have followed the FAQ SiLK — FAQ<https://tools.netsa.cert.org/silk/faq.html#process-asa>, but it hasn’t resolved the issue. Below are the relevant configurations from sensor.conf and silk.conf. The sensor for the firewall is named "rogersPrdFw".

--- sensor.conf ---
probe probe_rogersPrdFw netflow-v9
  listen-on-port 9988
  protocol udp
  accept-from-host 10.146.64.116
  quirks firewall-event zero-packets
end probe

--- silk.conf ---
sensor 5 rogersPrdFw "cgy-gca-r0306-01-ngfw-prd-ha"
class all
    sensors cvrlWanDist cvrlWanDistA netflow1cisco netflow2juniper rogersPrdFw
end class

I have also been reviewing the rwflowpack logs:
Jul 16 17:07:10 grfprd003z rwflowpack[3428204]: 'probe_rogersPrdFw': accepted connection from 10.146.64.116:60395, domain 000000
Jul 16 17:07:10 grfprd003z rwflowpack[3428204]: 'probe_rogersPrdFw': noticed disconnect by 10.146.64.116:19124
Jul 16 17:07:10 grfprd003z rwflowpack[3428204]: NetFlow V9 sequence number mismatch for domain 0x0000, expecting 0x0000 received 0x0001
Jul 16 17:07:10 grfprd003z rwflowpack[3428204]: Ignoring template 0x0100: Template warning: Illegal length 12 for information element ciscoNetflowGeneric
<repeating…>

The sequence number error always shows the expected value as one less than the received value in the repeated messages.

Here is a packet capture of the flow packets. It was collected earlier on a different port (2055), but everything else remains the same:
https://www.dropbox.com/scl/fi/8qlgu1h4zfrw77t3pejog/fw-2055.pcap?rlkey=vnzxvrqimrn7tszzi2qwjwsxt&st=4te8505g&dl=0

Any help or guidance would be greatly appreciated.

Thanks,
Difan


________________________________

---------------------------------------------------------
If you wish to no longer receive electronic messages from this sender, please respond and advise accordingly in your return email.

This email and its contents are private and confidential, for the sole use of the addressees. If you are not an intended recipient, copying, forwarding or other distribution of this email or its contents by any means is prohibited. If you believe that you received this email in error please notify the original sender and delete this communication and any copies immediately.

Petro-Canada is a Suncor Energy business.

150 – 6th Avenue S.W., Calgary, Alberta, Canada, T2P 3E3 (Corporate Head Office) / www.suncor.com<http://www.suncor.com/>

------------------------

Si vous ne voulez plus recevoir de messages électroniques de cet expéditeur, veuillez l’en aviser en répondant à ce courriel.

Ce courriel et son contenu sont privés et confidentiels, et sont destinés à l’usage exclusif des destinataires. Si vous n'êtes pas le destinataire prévu, toute reproduction, transfert ou autre forme de diffusion de ce courriel ou de son contenu par quelque moyen que ce soit est interdit. Si vous croyez avoir reçu ce courriel par erreur, veuillez en aviser l’expéditeur original et supprimer cette communication et toutes ses copies immédiatement.

Petro-Canada est une entreprise de Suncor Énergie.

150 – 6th Avenue S.W., Calgary, Alberta, Canada, T2P 3E3 (siège social) / www.suncor.com<http://www.suncor.com/>

<sensor.conf><silk.conf>

-------------- next part --------------
HTML attachment scrubbed and removed