09-05-2008 07:14 AM - edited 02-21-2020 02:59 AM
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 0.0.0.0 0.0.0.0 FastEthernet4
to
ip route 0.0.0.0 0.0.0.0 192.168.0.254
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?
09-07-2008 04:12 AM
Jonathan
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.
HTH
Rick
09-08-2008 04:37 AM
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.
09-08-2008 09:12 AM
Jonathan
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?
HTH
Rick
09-08-2008 10:09 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: