cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3060
Views
40
Helpful
16
Replies

Netflow via ASA 5512 managemet interface

Hi there,

 

I have an ASA 5512 running 9.9(2)18, and I am trying to make it send Netflow traffic out of its management interface to collector in an adjacent subnet. I used a number of the simple tutorials available in the public domain.

 

It just won't work; although all of the routing configuration is in place, tcpdump on the collector shows me that no traffic from the ASA is coming in, even though ADSM shows that the ASA is sending plenty of UDP packets to that destination.

 

When I add a Netflow collector to the 'flow-export destination' that is on the inside interface however, that collector happily receives the traffic.

 

Are there any limitations about a 5512 sending Netflow traffic out of the management interface?

 

Mat

16 Replies 16

Francesco Molino
VIP Alumni
VIP Alumni
Hi

I don’t recall any limitations on that part, and maybe others will agree or disagree to validate this point.

Personally i use management interface for OOB only purpose so never send netflow data from there and use the actual inside or dedicated monitoring zone.

Anyways, you said you see plenty of udp packets sent by asa towards your netflow collector but nothing coming in which seems to tell us asa isn’t the issue.
Just to clarify, these udp packets are netflow packets right?
From the netflow collector, are you able to ping the asa management ip?
Have you run a tcp dump to validate what asa is sending is received by your netflow collector server?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hi Francesco,

 

I am sorry I was not clear.

 

My main collector is on my management network. With tcpdump I can see UDP traffic coming in from other exporters, but nothing coming in from my ASA. I can also ping this collector from the ASA's mangement interface. ASDM shows me that the ASA *thinks* that it's sending this traffic ( Monitoring > Properties > Connections ).

 

For the purposes of troubleshooting I deployed a new collector on my inside network. With no change to the ASA config, other than adding this collector new IP address, this new collector can see netflow traffic.

 

Mat

Did you take a capture on asa to validate the netflow are sent or not?

Not sure I can have a 5512 to test it.

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hi Francesco,

 

Yes I just did a packet capture via the CLI, which I've dropped in a another reply on this thread. No packets matching my criteria leaving the management interface.

 

Thanks.

 

Mat

Marvin Rhoads
Hall of Fame
Hall of Fame

I don't have a 5512-X handy to verify it but as far as I know it should work. The management interface is actually the preferred interface for sending Netflow.

The config should look something like this:

flow-export destination [Source_Interface_For_Sending_Flow] [flow_collector_ip_address] [flow_collector_port]
flow-export template timeout-rate 30
flow-export active refresh-interval 1
!
policy-map global_policy
  class class-default
    flow-export event-type all destination [flow_collector_ip_address]

 Also, make sure you have a management-only route to reach the collector if it's not on the same subnet as your ASA management interface.

Hi Marvin,

 

The only difference between your and my config is that my 'flow-export event-type' command was in a non-default class. I copied into class-default and there is no difference... still no netflow traffic from the management interface to my collector, and the netflow traffic to my second collector on the inside network is still working fine.

 

Thanks.

 

Mat

The class can be either default or otherwise - as long as you're consistent.

The only other thing I can think of configuration-wise is to double check your nameif for your Management interface against what's configured in the Netflow config. Make sure any capitalization and spelling matched exactly. If that's ok, then I'd suggest a packet capture from the ASA.

I'm using an ASAv in my lab and Netflow from the management interface works fine. This Cisco document (albeit from 2014 but the core tech hasn't really changed) notes that management interface is recommended:

https://www.cisco.com/c/en/us/td/docs/security/asa/special/netflow/guide/asa_netflow.html#pgfId-1341494

The "flow export" command hasn't changed since 8.1:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/A-H/cmdref1/f2.html#pgfId-2018347

Hi Marvin,

 

I double-checked the nameif. It's the same.

 

Here's a packet capture.

 

ASA1# capture quack1 interface management match udp any4 any4 eq 2055
ASA1# capture quack2 interface inside-ACI match udp any4 any4 eq 2055

# ... wait one minute ...

ASA1# show capture quack1

0 packet captured

0 packet shown
ASA1# show capture quack2

10 packets captured

1: 13:52:12.986658 10.255.255.1.51163 > 10.120.69.69.2055: udp 1032
2: 13:52:18.014815 10.255.255.1.51163 > 10.120.69.69.2055: udp 816
3: 13:52:23.042951 10.255.255.1.51163 > 10.120.69.69.2055: udp 1008
4: 13:52:26.931531 10.255.255.1.51163 > 10.120.69.69.2055: udp 1436
5: 13:52:26.931546 10.255.255.1.51163 > 10.120.69.69.2055: udp 1276
6: 13:52:28.071117 10.255.255.1.51163 > 10.120.69.69.2055: udp 580
7: 13:52:33.099177 10.255.255.1.51163 > 10.120.69.69.2055: udp 404
8: 13:52:38.127312 10.255.255.1.51163 > 10.120.69.69.2055: udp 300
9: 13:52:43.155417 10.255.255.1.51163 > 10.120.69.69.2055: udp 644
10: 13:52:48.183553 10.255.255.1.51163 > 10.120.69.69.2055: udp 472
10 packets shown
ASA1#

 

I've inherited this ASA configuration :( I will have to go through it with a fine-toothed comb to work it out. Thanks for your help though. Much appreciated. 

 

Mat

So you see packets send from asa to your netflow collector only on the inside.

Can you run a packet-tracer to validate nothing is being blocked by a policy or other?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hi Francesco,

 

I have never used packet-tracer for traffic originating on the ASA, only traffic that comes in via one interface and goes out the other. I am not sure that I'm using the command correctly.

 

ASA1# packet-tracer input management udp 10.128.114.9 24506 10.128.113.36 2055

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.128.114.1 using egress ifc management

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: management
input-status: up
input-line-status: up
output-interface: management
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

ASA1#

 

Interestingly, I get the same result when I simulate a ping packet (packet-tracer input management icmp 10.128.114.9 8 0 10.128.113.36) but I know that the ping actually works.

 

When I clear the asp drop counters I can see that these acl-drop counters start incrementing as roughly the same rate that I expect the netflow packets to be going out.

 

ASA1# show asp drop

Frame drop:
NAT-T keepalive message (natt-keepalive) 2
Flow is denied by configured rule (acl-drop) 20

... snip...

 

Is there a way that I can see any specific information about these drops?

 

Mat

Can you run a capture type asp-drop and see what happens when netflow packets are sent?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hi Francesco,

 

Nothing! Those acl-drop counters must have been something else on the other interfaces.

 

ASA1# capture quack3 type asp all match udp host 10.128.114.9 host 10.128.113.36

# ... wait a few minutes
ASA1# show capture quack3

0 packet captured

0 packet shown

 

The only proof that I have the firewall is sending these flows out is via the 'Connections' screen in ASDM. I have attached that diagram. Whatever is dropping these packets is after the ASDM monitoring and before the capture.

 

001.png

 

I am at a loss. I have been trying to glean info from public domain sources and I can't find anything. Do you have any more ideas?

 

Mat

The only thing I would do to make sure ASA is actually sending this traffic is to do a span on the switch right behind the asa to validate you see it

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Thanks, Francesco.

 

It's going to take me a while to get physical access to this device again, but I will check.

 

I appreciate your help.

 

Mat

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: