Thanks for the quick reply. This solution might be a viable option at some of our smaller sites, but could be an administrative nightmare for larger VPN mesh hub sites. In order for me to be able to troubleshoot potential upstream routing issues I need to know the expected behavior of the ASA. I guess my only real question is, can routes to subnets on the far end of the l2l vpn tunnel (10.2.2.0/24 in our example) dictate the next hop for the ASA? Since ultimately the packet is encrypted, and its new destination is the IP terminating the far end of the tunnel (2.2.2.1 in our example), to me the route to 2.2.2.1/32 should be the only factor. Again, I never questioned this until recently when we experienced symptoms that would indicate otherwise. I just need to know if this is by design or are we potentially hitting a bug.

One thing I neglected to mention in the original posting is that we are NOT using OSPF across the l2l VPN tunnel. It is only being used between the ASA and external WAN routers.

Thanks again for any additional clarification.

Aaron

Thanks, this is the exact document I was hoping to find the equivalent of for ASA “routing order of operation,” or something like that. Let me ask the question a different way. Use the same diagram, but assume no NATing (only static translations) and this time OSPF is turned off. The ASA has only two routes:

1. one static for 2.2.2.1/32 through Router2

2. a default gateway through Router1

As a result, traffic destined for 10.2.2.0/24 would only be covered under the default gateway. IF the ASA looks at the routing table prior to encryption (as indicated in the “NAT order of operation” page for 'Inside-to-Outside') then the packet should get sent to Router1. However, if the ASA looks at the crypto map, encrypts the packet and then looks at the routing table, the packet should always go through Router2.

To me the latter is the only one that makes any sense, but I can't find a document describing the expected behavior. If anyone knows of a link reinforcing or disproving this description I would be grateful.

Thanks again.

It seems clear now, I think there may be an issue , as far as I know ASA/PIX does not support PBR so if you have a static route say " route ouside 2.2.2.1 255.255.255.255 Router2 1" ASA will not do policy route but instead use default route which is Router1... is router1 the ASA default route?

There are no statics pointing to the outside, not even a default. The ASA receives all routes, including a default from the external routers. Depending upon what is going on throughout the WAN the ASA may receive a default (and the routes for the other VPN endpoints) across the mesh from either router1 or router2. This all works fine. The VPN tunnels themselves have never gone down. However, the ASA is also receiving some routes via OSPF for internal networks that are on the far end of the tunnel (10.2.2.0/24 in the initial fictitious example). Are these routes necessary? I don't see why they would be, but it isn't something I can easily test either.

Thanks.

Hi Aaron

In a standard l2l setup no the routes for the remote networks are not needed on your ASA because the crypto map access-list is what tells the ASA to send traffic for the remote network down the VPN tunnel.

The ASA only needs to know how to route to the peer VPN addresses.

Jon

Hey Jon,

Thanks a million for the response. This is what I was hoping to hear. Do you happen to have any links to a document that might reinforce this? For some reason your statement is difficult to produce by way of Cisco documentation, or at least my interpretation of the seemingly pertinent pages. I started this thread because we experienced symptoms that could imply having the unnecessary routes caused problems. However, after the 'issues' had been resolved I found myself at a loss for words as to what “should” be the expected behavior in this case.

Aaron

Aaron

I'll have a hunt around but i don't remember seeing any document that specifically states this. It's just from experience of setting up l2l vpns.

I suspect if you did have routes for the remote networks this could cause a problem. If i get time today or tomorrow i'll lab it up and see what the results are.

Jon

Hi Aaron,

You should bear in mind that the remote network (on the other side of the tunnel) should be routed to the outside interface. The next hop IP doesn't matter, as long as it is on the outside interface. Doing so will trigger the crypto engine to encapsulate the traffic, and from that point only the routing for the VPN peer is relevant.

But if you route the remote network to e.g. the inside interface, the encryption process will never be triggered. So, the only relevant routing option for the remote network is that it should be routed to the correct interface. To make sure this happens you can use the route-injection feature.

Good luck,

Erik

Hey Erik,

Thanks for the feedback. We don't have any overlapping routes pointed to the inside. I think we may just be recieving some unnecessary routes via OSPF (from the outside). They aren't causing any problems since they also point to the outside. However, since they are not needed they add confusion during troubleshooting.

Thanks.

Hey Jon,

If you have time that would be great. I certainly appreciate your help.

Aaron