cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
481
Views
0
Helpful
4
Replies

IPSEC Lan to Lan Possible Bug, ASA and 871 Router

taelon_x7
Level 1
Level 1

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?

4 Replies 4

Richard Burts
Hall of Fame
Hall of Fame

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

HTH

Rick

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.

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

HTH

Rick

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.

Getting Started

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:

Review Cisco Networking products for a $25 gift card