06-15-2020 06:20 PM
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
06-15-2020 07:49 PM
06-15-2020 08:15 PM
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
06-15-2020 08:26 PM
06-15-2020 10:24 PM
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
06-15-2020 07:52 PM - edited 06-15-2020 07:54 PM
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.
06-15-2020 08:38 PM
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
06-15-2020 08:59 PM - edited 06-15-2020 11:17 PM
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:
The "flow export" command hasn't changed since 8.1:
06-15-2020 10:22 PM
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
06-16-2020 08:27 PM
06-16-2020 09:36 PM
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
06-17-2020 07:44 PM
06-18-2020 12:25 AM
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.
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
06-19-2020 06:38 PM
06-24-2020 06:21 PM
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
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: