• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 804
  • Last Modified:

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 (10.26.0.0 /24) and need to contact the tower at 10.0.108.0 /22.

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

I cannot ping from the 10.26.0.0 /24 network to 10.0.108.1, 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!
Simple-Diagram.pdf
0
enervest
Asked:
enervest
  • 6
  • 5
1 Solution
 
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 10.0.108.0 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?
0
 
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 10.0.108.0 0.0.3.255 10.26.0.0 0.0.255.255 (30 matches)
0
 
Darrell PorterEnterprise Business Process ArchitectCommented:
And is the reverse ACL on the CO ASA?  Is the ACL traversal rule on the FO ASA?
0
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

 
enervestAuthor Commented:
The ACL's are in place and seem to be working.

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

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


What do you mean by ACL traversal rule? I do suspect a NAT (or something else?) issue on the Field Office ASA.
0
 
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?

https://supportforums.cisco.com/docs/DOC-5796
0
 
enervestAuthor Commented:
I am in the process of doing so now.

When trying to ping from 10.26.1.X to 10.0.108.1, would my traffic enter and exit on the outside interface (VPN tunnels) of the Field Office ASA?
0
 
Darrell PorterEnterprise Business Process ArchitectCommented:
Essentially.  The traffic should never hit the inside of the FO ASA.
Have you reviewed
http://www.cisco.com/en/US/docs/security/asa/asa91/configuration/firewall/nat_overview.html#wp1285965
0
 
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?
0
 
Darrell PorterEnterprise 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
http://blog.braini.ac/?p=38
0
 
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!
0
 
enervestAuthor Commented:
same-security-traffic permit intra-interface was the fix!
0
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.

Join & Write a Comment

Featured Post

Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now