hi guys, we have a hub (3640) and 40 spokes (1841), our requirement is, whenever a server at branch wants to communicate with any1 in the network it should go through HUB through VPN. at branch site the configuration is simple
now as you can see that i have to make different ACL for every spoke, is there a workaround ?? i used a generic access-list stating
per ip 10.0.0.0 0.255.255.255 10.0.0.27 0.255.255.0
but the problem with this access-list is that it always get matches in the first XYZ_MAP 10 statement and tries to form VPN with spoke 1 even if the traffic should be going to spoke 2, means when traffic from spoke 2 wants to go to spoke 3 the first statement in crypto map matches this traffic ( 10.0.0.0 --> 10.1.3.27 ) so it tries to form VPN with Spoke1 which should have been made with correct spoke3, so do i have to make seperate access-list for all the spokes ?? or do you guys prefer going for CA ?? we dont want to make our configuration large until its a last choice,
So what do you guys prefer ?? if CA then which 1 ??
Using the statement " per ip 10.0.0.0 0.255.255.255 10.0.0.27 0.255.255.0 " would mean trying to estabish VPN with the first available ip address which would be 10.1.1.27. So I would prefer to use seperate statement for each though it is tedious.
Dear Joe, DMVPN has some issues, first it requires that out of 2 sites one should have a static statement, so if i give static statement at spoke, traffic from spoke to hub will go through a vpn tunnel, but what if traffic initiates from the hub ?? since it doesnt have any static statement how will it form tunnel with a specific spoke ??
With DMVPN, the tunnels are always up (unless there is a connectivity issue of course).
More detailed answer: the spokes register themselves to the hub using NHRP. This NHRP traffic will bring up the tunnel and keep it up, and will cause the hub (the NHS in NHRP terminology) to learn the mappings between transport network ip address (physical ip) and overlay network ip address (tunnel ip) of the spokes.
That said, if you really want you can also define static NHRP entries on the hub. I've never seen anyone do this though.
If the 3640 is sufficient for the task, depends on whether it has a hardware crypto accelerator installed, how many tunnels it needs to terminate, and more importantly how much traffic it needs to encrypt/decrypt.
For a few Mbps of traffic and not too many spokes connecting at once, it should do the job.
But as Joe mentioned, it will be EoL on December 31, 2008 so don't expect software updates or TAC support after that.
Hebaerte, 3640 is not of an issue, we are replacing it with either 3845 or 2821, currently i am worried about which design shall i follow, Static Site-to-Site VPN, or DMVPN ? we sure have connection issues with links going down so will it gonna cause much trouble even when the link is up ? ( like vpn not forming correctly and requires tough troubleshooting) so i am asking of your guys experience here to help me choose a better design .
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...