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

ASA VPN not passing traffic

I have a site-to-site VPN set up between two ASA 5505s.  VPN tunnel comes up fine, no errors in debug.  

When performing a ping to known good device through the tunnel, I get no reply.  Tunnel session statistics on the source ASA shows Tx traffic going outbound but NO Rx coming back.  Tunnel session statistics on the destination ASA show traffic going both ways (echo inbound and the echo-reply going back out).  Seems like the echo is getting there and most likely back but traffic somehow being stopped on the receiving end.

Both of these ASA units have other tunnels to other units up and running fine.

Tunnels are allowed to bypass incoming access list.  Routes are verified.   ACL on inside interface verified.  NAT exxempt looks ok (like the other tunnels I have).  IKE and IPsec are AES256 DH5 PFS enabled preshared keys.  Very simple setups!

Unfortunately these units are on a private WAN so I can not post the configs without retyping manually.  

Any suggestions?

Kurt

0
Avi8r
Asked:
Avi8r
1 Solution
 
thesherminatorCommented:
anything in the show logs?
0
 
Avi8rAuthor Commented:
sh crypto ipsec stats on the local unit shows the outbound data incrementing but no inbound.  The distant end ASA shows traffic both ways.

Tunnel comes up and down very nicely, showing no errors.

With the sh int outside command for the local ASA, it shows dropped packets incrementing with the ping.  I believe the command to allow the tunnel traffic to bypass the outside ACL is global (applies to all)??  If this is the case, that's not the problem as the other tunnel on this unit works fine.  Make sense?

Is there another ACL somewhere that could prohibit data passage on the outside interface?

I will hand type parts of the config on this chain if necessary.

Kurt
0
 
geergonCommented:
What do you get if you do a packet tracer?

For example:
asa(config)# packet-tracer input inside icmp source_host 0 0 8 destination_host detail

Of course the source host and destination should be part of the interesting traffic.
You should see in which step the ASA is dropping the packet while travels the core of the firewall.

Verify that your firewall is not checking the packets as stateful firewall:
You should have the command (by default is active)

sysopt connection permit-vpn
or sysopt connection permit-ipsec
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
Avi8rAuthor Commented:
Packet tracer in ASDM (on both units) show no errors.  I though that to be very strange.  

If the sysopt connection permit-vpn command is global (applies to all), then that's not it.  I have another site-to-site VPN on both units and those run fine.  Does it apply to all or is it connection profile specific?
0
 
Avi8rAuthor Commented:
The problem turned out to be an external firewall blocking esp to the local ASA.
This is very strange (to me at least) that the tunnel would come up when specified traffic would attempt to pass, but no traffic would pass from the remote ASA to the local ASA through the tunnel.
Another words, both units accomplished phase 2 and there were no errors in debug indicating something was wrong, but it would not pass traffic from the remote end to the local end (where esp was blocked).
Thanks to all that tried to help.
Kurt
0
 
fgasimzadeCommented:
I have a similar problem. VPN is up and working, pings are ok, but sometimes pings disappear while vpn is up. After I issue clear crypto isakmp sa command, everything works fine again. What can be a possible issue with it?

Thank you in advance
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

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