IPSEC Lan to Lan Possible Bug, ASA and 871 Router

Unanswered Question
Sep 5th, 2008

When configuring an IPSEC tunnel between an ASA and Cisco 871 router, we were having issues with the router passing ISAKMP phase. Thinking there was a typo in the policy we double checked the config and could not find an issue. After troubleshooting, we found that changing the default route from:

ip route FastEthernet4


ip route

resolved the issue and the tunnel came up and established the connection. Now, why would having the default gateway point to the WAN interface cause the tunnels ISAKMP phase to fail?? In the past I have been able to use the WAN interface as the default gateway but it was with a 3000 concentrator. Any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Richard Burts Sun, 09/07/2008 - 04:12


This is most likely a result of the configuration of the provider router and not dependent on your equipment at all. When you configure the static default route with the ouput parameter as FastEternet4 rather than specifying the address of the next hop then the router must ARP for every address to which it is trying to reach. This works if the next hop router enables proxy-arp and it fails if proxy-arp is disabled. proxy-arp is enabled by default in Cisco IOS but increasingly some organizations are disabling proxy-arp as part of tightening security in their networks (and in this case reducing the overhead activity on their router providing service to you).

In the past your default static routes with the interface specified have worked because you were connected to routers which enabled proxy-arp and this time it fails because the next hop has disabled proxy-arp. If you want to verify this you could go back to your default static route with the interface specified, turn on debug arp (and terminal monitor if you are not on the console), and attempt to ping anything that is more than one hop away. I predict that you will see your router sending ARP requests and receiving no responses.

So this is not a bug, but it is the result of a feature.



taelon_x7 Mon, 09/08/2008 - 04:37

Well I would agree but the router was negotiating its ISAKMP phase with the ASA and would fail so that means that it had connectivity.

Richard Burts Mon, 09/08/2008 - 09:12


Since the ASA is configured to have an active VPN peering with the router then it would send ISAKMP packets to the router which would be received by the router. And the router would attempt to send ISAKMP to the ASA. But if my theory is right the attempt by the router to send ISAKMP to the ASA would fail. Debug crypto isakmp on the router would show receipt of ISAKMP and would show sending ISAKMP. But I question whether the ISAKMP actually made it out the outside interface. Are you sure that the ASA was seeing ISAKMP from the router?



taelon_x7 Mon, 09/08/2008 - 10:09

Yes, I didn't make a copy of the log but it was receiving the ISAKMP handshake and then start to match it to policy and would fail. You would get "No matching policy found" for the phase and then it would terminate the attempt.


This Discussion