Hey Shiva,

That is a good question. Anything on the ASAs Local Networks, or any network that use the ASA as a default route, will technically be apart of the Encryption Domain. If that needs to be limited to specific networks, then ACL rules or filters would need to be used to only allow specific local traffic to traverse the VPN.

With Route Based VPNs, there isn’t an actual encryption domain that is applied. If you look at the Security Association, you will see that both Local and Remote are 0.0.0.0/0. This is why everything on the ASA is apart of the VPN if the traffic is destined to anything with a Route using the VTI.

If you are troubleshooting and wanting to know what Local traffic is trying to use the tunnel, the easiest way is to perform a capture on all of the internal interfaces looking for anything destined to the VTI. Specifically, any network that is routed over the VTI. This will atleast show you all connections that are trying to send over the VTI but there is no quick way to determine which networks should have access. This is usually provided by either side stating what should be communicating over the tunnel.

Thanks for the post. My question is what is local encryption domain here. To identify the remote encryption, atleast we have static route in place. But while troubleshooting how to identify the actual interesting traffic participating in this tunnel ?

Regards,
Shiva

Are you asking for me to send a Topology or are you asking if you could send me a Topology?

John, Thanks again for this very detailed explanation! it’s really appreciated. Today i found something interesting: i couldn’t access the asa via ssh anymore when a connection came from a remote location over the VTI interface and running on version 9.8.2. This issue is fixed in version 9.9.1. See here as well https://supportforums.cisco.com/t5/vpn/ssh-snmp-access-to-asa-through-vti-tunnel/td-p/3226319

Here is an example:

show int tunnel 3 detail
Interface Tunnel3 "ROUTE-BASED", is up, line protocol is up
  Hardware is Virtual Tunnel    MAC address N/A, MTU 1500
    IP address 169.254.224.253, subnet mask 255.255.255.252
  Control Point Interface States:
    Interface number is 17
    Interface config status is active
    Interface state is active
  Tunnel Interface Information:
    Source interface: OUTSIDE   IP address: 1.1.1.1
    Destination IP address: 2.2.2.2
    Mode: ipsec ipv4    IPsec profile: ROUTE-BASED-PROFILE

***********************************************

show ipsec sa peer 2.2.2.2
interface: ROUTE-BASED
    Crypto map tag: __vti-crypto-map-7-0-3, seq num: 65280, local addr: 1.1.1.1

  local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
  remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
  current_peer: 2.2.2.2


  #pkts encaps: 101, #pkts encrypt: 101, #pkts digest: 101 <<----I have encaps (OUT)
  #pkts decaps: 101, #pkts decrypt: 101, #pkts verify: 101  <<---- I have decaps (IN)
  #pkts compressed: 0, #pkts decompressed: 0
  #pkts not compressed: 101, #pkts comp failed: 0, #pkts decomp failed: 0
  #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
  #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
  #TFC rcvd: 0, #TFC sent: 0
  #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
  #send errors: 0, #recv errors: 0

  local crypto endpt.: 1.1.1.1/0, remote crypto endpt.: 2.2.2.2/0
  path mtu 1500, ipsec overhead 74(44), media mtu 1500
  PMTU time remaining (sec): 0, DF policy: copy-df
  ICMP error validation: disabled, TFC packets: disabled
  current outbound spi: EDD1EBD7
  current inbound spi : 8A03B6F4

I am glad that you were able to get it to work and that is correct. If you had a VPN already, and are converting it to Route Based, you will need to remove the Crypto Maps that are referencing the VPN for it to work properly. Feel free to reach out anytime if you have questions.

Thanks John! Got it working now…The only issue was that if you replace a peer (in my case) you NEED to remove the old setup and SAVE the config before adding the new setup. If not, still old parts of cryptomaps etc do apply to same peer (stupid asa 😉

That is correct. It can be any IP range that you want it to be so long as it is not in use somewhere else in the network.