Problem exporting Netflow data over IPSec VPN Tunnel

[greggm]

I'm having problems exporting Netflow data from a Cisco 831 to a Netflow collector that sits on the other side of a VPN tunnel at my central site. I attached portions of the config in this posting.

The Netflow collector is addressed as 192.168.0.100 and the Cisco 831 is set to "ip flow-export source Ethernet0", "ip flow-export destination 192.168.0.100 9996" What I'm see is the access-list 101 is blocking the router from sending the data to 192.168.0.100.

Here is the log message on the Cisco 831 (192.168.2.1) when it exports the Netflow data to the collector (192.168.0.100)

000075: *Feb 28 19:27:04.841 PCTime: IPFLOW: Sending export pak to 192.168.0.100 port 9996 0

00076: *Feb 28 19:27:04.843 PCTime: %SEC-6-IPACCESSLOGP: list 101 denied udp 192.168.2.1(0) -> 192.168.0.100(0), 2 packets

One interesting note is that syslog messages "logging source-interface Ethernet0, logging 192.168.0.100" works great and syslog messages are showing up on the 192.168.0.100 server with no problem. It too uses the same Cisco 831 VPN tunnel to my central site. Is this an IOS bug or I'm I configuring something totally wrong? Help... I've been banging my head on this problem for weeks now...

[beth-martin]

Make sure that your "Netflow export source interface" is included as "interesting traffic" in your crypto ACLs. In other words, make sure that the proxy identity ACLs applied to the crypto map include the router source int.

[Richard Burts]

I am not convinced that access list 101 is preventing the router from sending the Netflow data. Access list 101 is used in the route map which controls NAT. I believe that the log meeesage you are seeing indicates that access list 101 has denied the packet and the effect of the denial is that the packet will not be translated. But it should still permit the packet to be transmitted. I would guess that there are instances of the access list 101 log message that are not associated with Netflow - is that correct?

HTH

Rick

[tomphilip]

Hi,

have you resolved this?i am experiencing the same issue.please let me know

[Richard Burts]

Thomas

It is not clear whether the original poster solved the problem. I would suggest that we may be able to help you with your problem is we had some information about your situation. Can you give us a bit more description of your problem and can you post the appropriate part of your config and any applicable log messages?

HTH

Rick

[tomphilip]

Hi Richard,

This is the config for 877 router for the standard netflow enabled on vlan1. this is a remote router connecting back to central office through site to site vpn ipsec(crypto map ). no data is reaching the server. the ios version is 12.4

i have configured another router with version 15 with flexible netflow on the same config .its the same situation on that as well. please assist. and thanks so much

sh run

[Richard Burts]

Thomas

Thank you for posting the configuration. Obscuring the interface addresses makes it difficult to be sure but I do not believe that any of the things that I suspected to cause the problem are problems here.

- I wondered if address translation might be causing the issue but it is pretty clear that you are translating 192.168.1 addresses and that the NetFlow source address is 10.something.

- I wondered if the NetFlow traffic might not have a permit in the access list for the VPN. But you do specify the source address for NetFlow to be the address of interface vlan1. And while you have obscured the address of vlan1 I am guessing that it does match a permit in access list 130.

Since neither of my first guesses seem to be the issue we need to do some more investigation. I would suggest a re-write of access list 130 as the first step. I will note that beginning the access list with permit ip 10.x.x.x x.0.0.255 any makes the remaining statements in the access list redundant. If you do show access-list 130 I expect that you will see the hit count for that line incrementing and no hits on the lines following it. I would like to start the access list with a specific permit for the addresses involved in NetFlow and then permit other traffic. I would suggest logic like this:

permit ip host host 10.

permit ip 10.x.x.0 0.0.0.255 any

If there is some reason to want the permits for the other addresses then you can add them as you wish.

I would suggest that you re-write the access list as a test. And since the access lists for VPN should be mirror images of each other at each end you would also want to re-write the access list on the headquarters end. When you do that you need to make sure that the VPN processing is picking up the access list change. You can either wait for the Security Associations to be renegotiated or you can clear crypto sa. You can verify that it is using the changed access list by checking the output of show crypto ipsec sa where it lists the conditions from the access list that it is using.

After you make the change let some traffic go through the VPN and do show access-list 130. If the line to permit the NetFlow hosts does have a hit count then we can be sure that NetFlow is going through the VPN tunnel - which means that the problem may be on the other end. If the hit count is zero then we need to look more closely at this router for the source of the problem.

HTH

Rick

[edit] I have obscured some addresses to comply with request from original poster.

[tomphilip]

Hi Rick,

thanks for that. I am going to test that and will update you.

Tom

[tomphilip]

HI Rick,

Those changes you suggested did work the magic and the packets started coming through. excellent and thanks so much. ITS WORKING

Tom