Netflow flow direction on v5 vs v9

[samplonius (Tom Samplonimus)]

The Netflow module forces v5 flows to be of direction ingress. But for v9 messages, the module uses the "direction" field from the message, but if "direction" is not included, the __netflow_direction_not_recognized tag is added.

The Netflow V9 RFC says the "direction" field is optional. So I'm not clear why the v9 path in netflow.conf.erb does not use the default of ingress, if "direction" is missing. That would be more comparable to how v5 processing works.

If direction is missing, a number of the Netflow dashboards do not work. A work around is to drop the exporters from v9 to v5, which is a surprising result.

This is with flows coming from a Mikrotik router running RouterOS 6.43.8. It has no concept of flow direction, so never specifies it. RouterOS leaves it up to the Netflow collector to determine which interfaces are inside and which are outside.

I think most router flow exporters are setting the direction to ingress all the time, as most router exporters use ACLs to determine what traffic to export and it is considered best practice to only use ingress ACLs to match exported flows, to avoid double flow counting. Unfortunately, RouterOS exports flows on an interface by interface basis. An it all flows that transit the interface.

So would there be any consensus to change the default netflow.erb.conf to use ingress as the default direction on v9 messages?

[rcowart (Rob Cowart)]

Whether a flow is ingress or egress has nothing to do with whether the ingress is "inside" or "outside". It is related to whether the flow record was created based on traffic being received (ingress) on the monitored interface, or sent (egress). Netflow v5 is based only on received traffic and thus will always be ingress flows. However since v9 can produce flow records for both ingress and egress, there is no way to know which it was unless it is specified in the record. If a device sends Netflow v9 or IPFIX flow records and does not send a direction, I would consider that a bug.

Having said all of that, you may want to try ElastiFlow (https://github.com/robcowart/elastiflow). The Logstash Netflow module is based on ElastiFlow 1.0.0 and is very dated. The current release of ElastiFlow is 3.3.0 and has considerably more functionality.

The following article describes one user's setup of ElastiFlow to monitor Mikrotik.