10-30-2007 02:01 PM - edited 02-21-2020 01:45 AM
I have a basic conceptual question. If an ASA is using dynamic routing (OSPF), has multiple physical paths to the Internet (for redundancy), and a l2l VPN tunnel established to another site, does it look to the routing table prior to encrypting the packet, or the other way around?
Please see the attached diagram for an illustration of the following description.
Let's say that the ASA is running OSPF between its outside interface and the two external routers. Under normal circumstances the ASA may receive a route for 2.2.2.1/32 through router2, and simultaneously be receiving a route for 10.2.2.0/24 via router1. However, depending upon what is going on in the network it may receive these routes from the alternate router.
Is the ASA's local routing table having an entry for 10.2.2.0/24 a factor, or is only the route for the tunnel endpoint relevant? My understanding is that it was not, but we have experienced symptoms that would contradict this.
Thanks in advance.
Aaron
P.S. We are NOT using the 'tunneled' keyword for any static routes local to the ASA. Only traditional routing concepts should apply.
10-30-2007 02:45 PM
Can't really answer the conceptual question but what if you were to avoid the conundrum all together?
If 100% of the traffic is covered by your l2l tunnel, a static route on the ASA for 10.2.2.0/24 to 1.1.1.3 would work and then you'd only need to worry about getting OSPF routes to locate your peer at 2.2.2.1
10-30-2007 09:25 PM
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
10-30-2007 09:24 PM
This is my opinion but could be off..It all depends, on the routing and encryption process I think your conceptual question for l2l traffic scenario may be on this link NAT table , the same way NAT order of operation is performed on a device. From ASA l2l outbound traffic initiated from inside routing is looked at first before encryption. If using ospf on asa you have to take under consideration link bandwidth and traffic load of multiple paths since you indicated you have few routers in front of ASA for redundancy. As far as ASA local routing table route entry of 10.2.2.0 I don't think is a factor because you are sending the traffic through asa outside interface point anyways and from that point beyond is handle by dynamic routing.. one would have to look at how ospf routing is configured from routers front of asa including alternate router to see a better ospf footprint to comment further.
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml#intro
10-31-2007 05:10 AM
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.
10-31-2007 12:14 PM
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?
10-31-2007 01:40 PM
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.
10-31-2007 09:09 PM
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
10-31-2007 09:27 PM
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
11-01-2007 12:46 AM
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
11-01-2007 04:29 AM
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
11-01-2007 03:29 PM
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.
11-01-2007 03:26 PM
Hey Jon,
If you have time that would be great. I certainly appreciate your help.
Aaron
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide