Routing failed to locate next hop for TCP from outside:

Unanswered Question
Dec 10th, 2008

I have a vendor who uses an ASA at his end to build VPN tunnel to us. He gets the following error when he attempts to send traffic to us through the VPN tunnel. One thing to point out is that I am able to see his syn packet come to the destination host located behind my side of the tunnel as well seeing as the syn, ack packet but never seeing the return ack packet. The appliance at the other end of the tunnel generated this error in their ASDM:

Routing failed to locate next hop for TCP from outside:our host:our port to inside: their host: their port.

My thinking is that the TCP SYN,ACK is not getting to their host explaining why the last ACK of the TCP 3way handshake is never seen at my side.

Any comments would be appreciated

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
John Blakley Wed, 12/10/2008 - 06:40

I'm assuming this is ASA --> ASA? On both ends, the ACL that's on the outside interface needs to allow esp, udp 500, and (possibly) AH through the firewall.

So if their public IP is, your ACL would be:

access-list VPN permit udp host host eq isakmp

access-list VPN permit esp host host

access-list VPN permit ah host host



yuchenglai Wed, 12/10/2008 - 08:06

Nortel on my end, ASA on their end. I will suggest that to them and see if that helps.

yuchenglai Fri, 12/12/2008 - 08:26


From what I understand, this is sounding more like IPSec than a route issue?

husycisco Fri, 12/12/2008 - 09:48

Hello Yu-Cheng,

Can you ask remote end if they have more than 1 interfaces facing internet with public IPs, and ask if they already have a route for for your subnet to somewhere else (maybe they have a site-to-site vpn with another company that has the same subnet with yours, or an internal network routed inside)

Also please ask them to run "debug crypto isakmp" and "debug crypto ipsec" and let them send you the output for you to paste here.


yuchenglai Mon, 12/15/2008 - 18:13

It turns out that this problem has been resolved by fixing a route problem on at the distant end controlled by the vendor. As the syslog message suggested they forgot to create a route on their border router/VPN Device to their newly created DMZ.


This Discussion