Cisco ASA VPN traffic not pass-through between tunnels

[FlyingFinn]

Hello:

I have a Cisco ASA 5525 (9.12) that has IPsec VPN tunnels to 2 other sites, Site-a and Site-b. VTI and BGP is used for the tunnel to Site-a, ACL policy based VPN is used for the other tunnel to Site-b. Site-a has subnet 10.10.0.0/16, Site-b has subnet 10.20.0.0/16. Both tunnels come up successfully, and I can access both sites without issue. However, I can't configure my ASA 5525 to be as a transit, to pass VPN traffic from one tunnel to the other tunnel, eg, to allow traffic between 10.10.0.0/16 and 10.20.0.0/16. In the past, I have done this between 2 ACL policy based tunnels.

Is this achievable? Any specific config needed for this scenario?

Thank you,

Finn

[Rob Ingram]

@FlyingFinn you will need to configure same-security-traffic permit intra-interface to allow the traffic to hairpin and be routed back out the same interface.

You will probably need a NAT exemption rule, example:

nat (OUTSIDE,OUTSIDE) source static SITE-A SITE-A destination static SITE-B SITE-B

Change the interface name and objects to fit your environment.

[FlyingFinn]

Hi Rob:

Thank you for your suggestion. I do have NAT exemption rule configured, but that doesn't help.

Thanks,

Tao

[Rob Ingram]

@FlyingFinn you configured same-security-traffic permit intra-interface as well?

Run packet-tracer from the CLI to simulate the traffic flow and provide the output for review.

[FlyingFinn]

Yes, same-security-traffic permit intra-interface is in place.

Packet-tracer shows drop at VPN. However, I don't consider this is an accurate assessment that I can rely on. I have no issue with VPN traffic between my site and Site-a which is through VTI based tunnel, but if I run packet-tracer I would get the same drop error. It seems to me that packet-tracer doesn't work well for VTI config

[MHM Cisco World]

I need to see the 
show route 
show ACL you use for policy VPN 

[FlyingFinn]

Thanks for your help.

Show route has entries for both Site-a and Site-b subnets like following:

B        10.10.0.0 255.255.0.0 [20/4294967294] via 169.254.0.2, 5d01h

S        10.20.0.0 255.255.0.0 is directly connected, Null0

and I have following 2 ACL lines that are referred by crypto map:

access-list ACL_VPN_SITE_B extended permit ip object-group MY_SITE object-group SITE_B 

access-list ACL_VPN_SITE_B extended permit ip object-group SITE_A object-group SITE_B 

[MHM Cisco World · Accepted solution]

S        10.20.0.0 255.255.0.0 is directly connected, Null0 <<- you config this to advertise the prefix to Site-A/B ? if yes then change it to OUT (same interface you config crypto map under it)
then check again.

[FlyingFinn]

That did the trick!

I had the similar thought, ie, a static route pointing to the tunnel. But I dismissed the idea because 1) ACL policy based VPN setup doesn't require static route, 2) a static route using public GW would send packets to public internet instead of tunnel. Would you mind sharing some insights why this is necessary, especially my 2nd concern. Thank you!

[SROD]

Using the detailed version of packet-tracer on the ASA is very helpful.  The tool (packet tracer) shows you the stages the ASA goes through to create the VPN.  Normally when I run into issues where traffic does pass through a VPN, it usually boils down to  a NAT statement (like MHM mentioned) or an issue with the crypto map.  I apologize for my explanation below as I am not sure how familiar you are with NAT/crypto maps. My only goal is to help.

Lets look at NAT.  The NAT statement that MHM mentioned usually is considered a no-nat statement. 

nat (INSIDE,OUTSIDE) source static SITE-A SITE-A destination static SITE-B SITE-B

It basically says, if the ASA sees traffic from the inside interface sourced from (SITE A) destined to  (SITE B) then NAT it in this way. Nat the source (SITEA) to (SITEA) , in other words don't NAT it and nat the destination address (SITEB) to (SITEB) which also means don't change it.  Normally, ASAs NAT traffic from the inside to the outside address and send it to the internet, this NAT statement prevents that.  It is important that the traffic is not NAT'D as the traffic is sent to the processor.  If it were accidentally NAT'd it would not match the crypto map. 

You will need a NAT statement for each network you are wanting to use in your VPN traffic and that NAT statement needs to be near the top of your NATs so any other NAT statements don't override it

Hint:  NAT statement can be done using object-groups/objects to prevent from having to have so many NAT statements

The second half of this is the crypto-map.  The crypto map acl needs to be written in one direction only.  Meaning, if you have (2) local nets and (2) remote nets, you need to write an ACL (probably using object-groups) that looks similar to this.  Try to summarize both locations if possible:

acess-list 101 permit ip 10.10.0.0 255.255.0.0 10.20.0.0 255.255.0.0

Your distant end ASA needs to have the same ACL in reverse referenced in it's crypto map

acess-list 101 permit ip 10.20.0.0 255.255.0.0 10.10.0.0 255.255.0.0 

When you use the command "show crypto ipsec sa" you can see which security associations are created for which networks.  Ultimately you need to ensure you have a crypto map for the traffic you are trying to send traffic between

it can If the VPN is up, then your phase 1/phase 2 configurations are correct (for at least one set of networks, but that doesn't mean all).  In order for vpn traffic to pass through, it must be analyzed and match the interesting traffic ACL (crypto-map).  

[FlyingFinn]

I use packet-tracer often to verify my VPN config, it works well in most cases, but I know from my past experiences there are cases it doesn't work, I think VTI based VPN application is one of them. In my case, even now everything works as expected, I am still getting drop error when running packet-tracer.