Trouble getting traffic to pass between multiple VPN tunnels

I am having trouble getting traffic to pass between remote VPN endpoints. I am leaning towards this being a NAT issue, but am unsure how to verify or remedy.

I have attached a diagram that lays out a simple topology.

I am sitting on the CO Network ( /24) and need to contact the tower at /22.

I am able to:
-Ping from the CO ASA to (inside interface on Field ASA)
-Ping from (Com Tower Router) to

I cannot ping from the /24 network to, which is what I need.

These tunnels terminate on the "outside" interfaces of the ASA's and all of my NAT exempt statements are applied to "inside" interfaces.

I'm sure configs pieces will be necessary, but I'll leave it at this for now.

Please help!
Who is Participating?
Darrell PorterConnect With a Mentor Enterprise Business Process ArchitectCommented:
I did not see an attachment to your most recent post.

Do you have these global configuration lines on the CO and FO ASAs?

same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

Also, while it is using pre-8.3 configuration examples, look at this configuration example - something similar is likely going to be needed on the FO ASA
Darrell PorterEnterprise Business Process ArchitectCommented:
What version of the IOS is on the ASA units in question?

Do you have
icmp unreachable rate-limit 1 burst-size 1

Open in new window

in the configuration of the ASAs?

Also, can you perform a NET VIEW to the systems on the network, or some other non-ICMP traffic?

Does the Field Office ASA have access lists configured to allow traffic from the Central Office to traverse to the Com Tower site?
enervestAuthor Commented:
Field is 8.25 and CO is 9.13

That command is on each ASA in question.

At this time, there is no other way to perform anything but ICMP tests.

There are ACL's configured for the traffic to pass, for example....this is configured on the Tower Router.
    10 permit ip (30 matches)
KuppingerCole Reviews AlgoSec in Executive Report

Leading analyst firm, KuppingerCole reviews AlgoSec's Security Policy Management Solution, and the security challenges faced by companies today in their Executive View report.

Darrell PorterEnterprise Business Process ArchitectCommented:
And is the reverse ACL on the CO ASA?  Is the ACL traversal rule on the FO ASA?
enervestAuthor Commented:
The ACL's are in place and seem to be working.

If I ping from the network, or ping from, I see the session being build on the Field Office ASA, but it doesn't get to the other side, for entry from a ping on to

7      Dec 17 2013      06:45:42                          Built local-host outside:

What do you mean by ACL traversal rule? I do suspect a NAT (or something else?) issue on the Field Office ASA.
Darrell PorterEnterprise Business Process ArchitectCommented:
There has to be a rule on the FO ASA for the traffic in each direction from the CT router to and from the CO ASA

Have you used the packet-tracer command on the two ASAs to determine at which point in the process the packet traversal is failing?
enervestAuthor Commented:
I am in the process of doing so now.

When trying to ping from 10.26.1.X to, would my traffic enter and exit on the outside interface (VPN tunnels) of the Field Office ASA?
Darrell PorterEnterprise Business Process ArchitectCommented:
Essentially.  The traffic should never hit the inside of the FO ASA.
Have you reviewed
enervestAuthor Commented:
Then it appears that's where my issue lies. Packet tracer shows an ICMP hitting an implict deny there, even when I've added an ACL on the outside interface allowing that traffic.

I have reviewed the document and my end to end issue will likely still persist once the ACL piece is resolved. Typically on ASA's, your NAT exempt statements are going to run from inside to outside, right?

In this scenario, I suppose this particular traffic would be "outside to outside", so I would need some NAT exempt rule with the proper source and destination, but I am not sure how I would go about applying that.

Please see the attachment for the packet tracer output and ACL. Packet tracer is saying the trace is denied due to the deny all, just two lines above my configured ACL.

What am I missing here?
enervestAuthor Commented:
same-security-traffic permit intra-interface

That ended up being the fix. Found that in a blog online as well which led me to try it, then came back here and saw you suggested it also.

All of my NAT statements and ACL's were good...I was just seeing the traffic drop unexpectedly at the Field Office ASA.

Regardless, thanks for the assistance!
enervestAuthor Commented:
same-security-traffic permit intra-interface was the fix!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.