Upload and download traffic for same internal ip showed as different clients

[fracarvic]

I'm using elastiflow 3.2.1 (ELK 6.3.1) with my home mikrotik router (RouterOS 6.42.6) using IPFIX, and when I see reports in Kibana I can see the outgoing and incoming flow for the same transfer with two different clients. The outgoing show the real ip client (private) and the incoming show the wan ip as client.

The follow image shows the problem:

Outgoing flow: flow.dst_addr => 194.71.11.142 (caesar.ftp.acc.umu.se public server) flow.dst_addr_trans => 194.71.11.142 flow.src_addr => 192.168.88.234 (private ip) flow.src_addr_trans => 37.X.X.X (wan ip)

Incoming flow: flow.dst_addr => 37.X.X.X flow.dst_addr_trans =>192.168.88.234 flow.src_addr =>194.71.11.142 flow.src_addr_trans =>194.71.11.142

Seems that mikrotik reports the final NAT destination in incoming flows as dst_addr_trans. I can't find any configuration in RouterOS than can change this behaviour.

Thanks.

[pukkita]

You can't change that behaviour.

For RouterOS these are two different (related) flows:

1. 192.168.88.234 <===> Router 2. Router <===> caesar.ftp.acc.umu.se

Doesn't matter if IPFIX or Netflow v9.

[pukkita]

I'd keep an eye on this related thread ;)

According to Rob's WTFlow article

Another concept which you will see is Traffic Locality. Logic implemented within Logstash identifies whether a conversation is between devices within the private network or whether a device from outside is a participant. This is useful for a number of use-cases, especially those related to possible security issues.

Related to Traffic Locality, the Geo Location of all public participants is determined. The information is summarized here as well as providing the basis for the Geo Analyzer dashboard.

So going back to RouterOS two different (related) flows:

1. 192.168.88.234 <===> Router Locality = Private
2. Router <===> caesar.ftp.acc.umu.se Locality = Public

[fracarvic]

Thanks @pukkita.

I don't know how, but may elastiflow can detect this behaviour and assign "flow.client_addr" to "flow.dst_addr_trans" for this kind of incoming flow ?

With this behaviour, I always have as first top client the wan ip, and can´t distinguish download traffic for each workstations.

[robcowart]

This is a valid use-case @pukkita. I just have to think about how to implement this. There are multiple possible NAT scenarios. Questions are... how to programmatically detect each from the available data? How to use that information to best reflect what is happening? I need to think through all of the possibilities, but am also open to input.

[pukkita]

Right now on Elastiflow 3.2.1, Flow (Sankey) Dashboard:

Bandwitdh cannot be inferred by this graph, but connection activity... is it apparent on the Vegas visualization that locality is being taken into account, you can easily spot what each client traffic is going. So maybe the logic used to create this visualization could be reused.

I know nothing prevents natting public IPs, but maybe taking into account locality, and private ranges a new dashboard or view could be created, where it would be great to have

• Uplink Public IPs with total traffic through each
• Uplink Public IPs with each client behind being masqueraded (useful in multi-wan)

[fracarvic]

I have done two small tests:

• Changing to netflow v5 seems that both "src_addr" and "dst_addr always" are the real endpoints, and there are not "trans" fields. Top clients are private ip's and wan ip only appears as traffic originated in the router (internal router dns server queries to external dns )

• Back to IPFIX, and modify this section in "20_filter_30_ipfix.logstash.conf"

    id => "ipfix_ipv4_mappings"
      rename => {
        "[ipfix][sourceIPv4Address]" => "[flow][src_addr]"
        "[ipfix][postNATSourceIPv4Address]" => "[flow][src_addr_trans]" I
        "[ipfix][sourceIPv4PrefixLength]" => "[flow][src_mask_len]"
        "[ipfix][postNATDestinationIPv4Address]" => "[flow][dst_addr]"
        "[ipfix][destinationIPv4PrefixLength]" => "[flow][dst_mask_len]"
        "[ipfix][ipNextHopIPv4Address]" => "[flow][next_hop]"
        "[ipfix][bgpNextHopIPv4Address]" => "[flow][bgp_next_hop]"
      }
    }

  to always take "postNATDestinationIPv4Address" as "dst_addr" and the result are fine, same as with netflow v5, client and server always are real endpoint ip's. Sure this change break things, but keep testing.

[robcowart]

This issue is being closed as this legacy version of ElastiFlow is now deprecated and is to be archived. Please try the new ElastiFlow, request a free Basic Tier license, and join the ElastiFlow Community Slack. Thank you.