Netflow from Internet Router

[fasteddye]

We are having an issue getting netflow stats from our Internet Router.  It is a Cisco 2800 series router running BGP protocol.

Doing the sh ip flow export shows exports happening

  Exporting flows to 64.xx.xx.55 (2055)
  Exporting using source interface GigabitEthernet0/1
  Version 9 flow records, peer-as
  31212406 flows exported in 1078150 udp datagrams
  0 flows failed due to lack of export packet
  1 export packets were sent up to process level
  0 export packets were dropped due to no fib
  0 export packets were dropped due to adjacency issues
  0 export packets were dropped due to fragmentation failures
  0 export packets were dropped due to encapsulation fixup failures

The Internet Router is at 64.xx.xx.1 and is exporting flows to 64.xx.xx.55.  We have the following on our ASA5520.

access-list OUTSIDE extended permit udp host 64.xx.xx.1 host 64.xx.xx.55 eq 2055
static (inside,outside) 64.xx.xx.55 10.xx.x.81 netmask 255.255.255.255

The 10.xx.xx.81 is the IP of server on inside of our network with netflow application running (Scrutinizer)

We never see any hits on the ACL.

Thanks.

[Jason Masker]

Are you sure your NAT statement on the ASA is correct?  Typically for something like this, my ASA config would be:

object network obj-[INSIDE IP]

host [INSIDE IP]

object network obj-[INSIDE IP]

nat (inside,outside) static [OUTSIDE IP]

Otherwise, your statement may be in a global format (not using objects) that is acceptable, but I would guess in that case that your outside & inside IPs might be swtiched. Is this host able to communicate out on that IP to other services?

Jason

[Giuseppe Larosa]

Hello Fasteddye,

may you post on BGP router

show ip route 64.xx.xx.55

Also I would suggest to use directly the private IP address of scrutinizer as the export destination adjust ip routing accordingly.

I don't see a good reason to NAT the netflow destination.

also take in consideration that export packets flow from outside to inside only the collector does not talk to the router

so NAT may not be triggered or the router is trying to send packets to the wrong next-hop

Hope to help

Giuseppe

[fasteddye]

Could you help explain further to not have to NAT this?

Here is the show ip route 64.xx.xx.55

Routing entry for 64.xx.xx.0/24

  Known via "connected", distance 0, metric 0 (connected, via interface)

  Advertised by bgp 65535

  Routing Descriptor Blocks:

• directly connected, via GigabitEthernet0/1

      Route metric is 0, traffic share count is 1

What would the route statement be to route to internal network?

If doing that I would not need NAT on firewall, maybe just an ACL?

-Ed

[Giuseppe Larosa · Accepted solution]

Hello Ed,

yes what you would need is a static route for the scrutinizer ip address with next-hop = ASA outside interface

natting these packets is probably just a waste of resources on the firewall as private addresses are not routed on external interfaces of your border router with appropriate ACLs.

for example in my setup I have:

router#show run | inc flow-export

ip flow-export source Loopback0

ip flow-export version 5 origin-as

ip flow-export destination 172.20.25.10 2226

in my case the border router receives the route in OSPF but a static route could do the trick.

My ASA allows sending to UDP port 2226 from network side to inside with no NAT.

it can also be a question of order of operation: if NAT is perfomed first the ACL should look for the translated address and not the pre-NAT address

this could explain why number of matches is 0 for the ACL statement  and no packets reach the scrutinizer.

also check that the router is actually sending to the ASA by comparing

show ip arp 64.xx.xx.55

with MAC address in ASA outside interface they must match or the router is sending packets to somebody else!

Hope to help

Giuseppe

[fasteddye]

Thanks for the recommendations.

I configured a static route on the internet router for 10.10.2.81 255.255.255.255 64.xx.xx.2. The 10.10.2.81 is inside address of netflow collector and the 64.xx.xx.2 is outside interface of ASA5520.

sh run | in flow-e

ip flow-export source GigabitEthernet0/1

ip flow-export version 9 peer-as

ip flow-export destination 10.10.2.81 2055

I have the following ACL in place on ASA5520 and it shows hits, access-list OUTSIDE extended permit udp host 64.xx.xx.1 host 10.10.2.81 eq 2055

I know see this in the log from ASA

5 Oct 22 2010 08:44:50 10.10.2.81 2055 Asymmetric NAT rules matched for forward and reverse flows; Connection for udp src outside:64.xx.xx.1/50847 dst inside:10.10.2.81/2055 denied due to NAT reverse path failure

Not exactly sure what that means.

-Ed

[Giuseppe Larosa]

Hello Ed,

so there is some progress

the ASA log message means that you need to find a way to tell it that that address 10.10.2.81 can be seen on outside interface

if you haven't already done you need to remove the nat rule that was present before in ASA configuration

Hope to help

Giuseppe

[fasteddye]

Well maybe...

I had removed the NAT rule that was in place before.

Then in my attempt to fix log message, I did the following.

What would adding this following do? I tried to add a Nat exempt (inside interface with any source and destination 10.10.xx.81)

access-list inside_nat0_outbound extended permit ip any 10.10.2.81 255.255.255.255

I added that and the log messages stopped happening and then I removed it and now I don’t see hits on the ACL anymore.

[Giuseppe Larosa]

Hello Ed,

read the NAT chapter in ASA config guide

http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/cfgnat.html

see section named bypassing NAT

Hope to help

Giuseppe