I have a basic IPSec tunnel between a 1841 (site a) and a non-cisco (site b) router. All appears okay but the only way I can ping site b from the 1841 is to source the private interface. How can I make is so this is permanent? I would like syslog and netflow data to go to a host on site b (originating from the 1841), but it doesn't know where to go.
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).
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...