well, the logging source-int worked perfect, but Im still not getting netflow data over the VPN.

Any more ideas?

Thanks

Greg

Greg

Using commands to specify the source interface for various kinds of traffic is a very good solution. But when it does not work (or a source interface command does not exist for that kind of traffic) there is another alternative.

To understand the alternative first let us be clear how the IPSec VPN works. There is an access list which is used to determine which traffic should be carried through the VPN tunnel. Typically that access list specifies traffic with source addresses from the inside network (and includes the router inside interface). So traffic which is sourced from the outside interface typically does not match and does not go through the tunnel.

So an alternative is to add statements to the access list which will match and permit certain types of traffic which are sourced from the outside interface address (such as your netflow).

HTH

Rick

"So an alternative is to add statements to the access list which will match and permit certain types of traffic which are sourced from the outside interface address (such as your netflow)."

You're making it look harder than

necesarry. The previous solution I

suggested work fine. I just tested it

between a Cisco 3640 and a Checkpoint NGx

firewall site-2-site VPN and that the

NetQoS netflow collector sit behind the

Checkpoint NGx firewall. I was able to

source the Netflow from in internal

interface of the 3640.

When things do not work and if the

source-interface option is avaible, one

needs to troubleshoot as to why it is

not working.

my 2c

Your 2c is appreciated. Greg stated that he had not gotten the NetFlow to work and asked for other ideas. I gave him another idea, as he requested.

If he were to ask which is the better solution I would agree that setting the source interface is preferable. But that is not what he asked. And I answered the question that he did ask.

HTH

Rick

agreed. I was preparing my switch to dump the traffic to my desktop so I could sniff it and establish the culprit. I did find numerous other examples where other users had the same issue. Seems there might be a bug in some versions when netflow is sourced from same router that is also doing non tunnel type VPN. I did not research fully as I learned that my monitor package handled ver 9 netflow so I setup flex netflow instead and it works.

thanks for the help.

Greg