The purpose of this access list is to identify what traffic must be encrypted using the crypto map. This access list must match user traffic. If we want to encrypt anything and everything that goes over the GRE tunnel, then we must use an access list that matches everything. This is why we use the any any keywords.
If you were to use the access list you suggest, then nothing will be encrypted. This is because the access list matches tunneled traffic, that is, the IP headers of the packets encapsulated inside GRE. The IP addresses in your ACL are on the IP header of the outside or encapsulating IP packet.
Yes, this is the case. You can see how this is done in the following lesson:
Why are there different approaches? Well, using a profile is considered a newer and simpler way to implement it. Using a crypto map and access list is the āolderā way. Itās just a matter of evolving technologies and implementations. If the equipment supports it, using the new way is much simpler and less prone to errors, so it is preferable.
Let me have a think, because I actually created a lab and it seems that using GRE tunnel IP addresses to identify the traffic works, but I might be wrong.
In the meantime, I think I noticed a typo in the lesson Cisco IPsec Tunnel Mode Configuration:
Last but not least, weāll activate the crypto map on the interface:
My apologies, my previous post was incorrect. It is the IP addresses of the GRE tunnels that are being matched here, not the tunneled traffic itself. So you could indeed specify the specific tunnel addresses in the ACL and the result would be the same.
Just a note here, in your configuration above, it seems that you are permitting specific hosts (the tunnel IP addresses) but in your second ACL statement you are permitting everything, which is redundant. You can either permit everything, or choose to permit only the addresses of the tunnels. In any case, the result is the sameā¦
I actually created the second ACL intentionally, to make the sure the tunnel worked before checking which of the two permit statements was actually being used.
I stumbled upon an issue when I tried to implement this.
When I try to apply the crypto map to the interface, my ospf configuration stops working.
The interface thats connected and my tunnel changes itās state to down.
Any idea on why that could happen?
The only situation in which I can think of that this would happen is if you havenāt implemented the static routes between the Branch, ISP, and HQ. Youāll notice at the very beginning Rene creates static routes between these three routers in order for communication to take place between all three for the purpose of establishing the tunnel.
If you have configured these routers to share these routes via OSPF (specifically the 192.168.12.0/24 and 192.168.23.0/24 subnets) then once you enable the tunnel, you will get what is called a GRE tunnel recursive routing error, where OSPF neighbors will be dropped, and the tunnel fails.
More information about this error can be found at this lesson:
Check to see if that is the case. If not, give us some more information so we can help you with the troubleshooting processā¦
On your DMVPN post you setup same thing but add the HASH:
I am working in live environment and I saw one side had HASH of SHA and saw some co-workers building another side and didnāt put in HASH.
Since they was using a template (Mail Merge) I figured if you left HASH out it might just automatically default to the standard otherwise their mail merge template would have not worked in the past but was unsure so just to be safe I asked them to put it in.
I saw the HUB side had a HASH of SHA in the Crypto isakmp policy 10 and figured could be possibility of mismatch if not added but not sure.
The hash command under the IKE policy is used to specify the hash algorithm to be used within that policy. The default is SHA, which means if you donāt specify it, SHA is configured. This is why the specific implementation you described works, because one end is explicity configured as SHA, and the other is by default SHA. In the case of the DMVPN over IPSec lesson, a non-default configuration of sha256 was chosen, and that is why the command appears.
For more info about the hash command under the IKE policy configuration mode, take a look at this Cisco command reference:
Yes that helps confirm what I thought. It always makes me feel better to get confirmation of how the world works well in this case some theory on networking IKE!
When you apply the crypto map on the tunnel interface, you are employing IPSec over GRE while when you apply it on the physical interface, you are employing GRE over IPSec. Yes both seem to work, but they do different things.
Take a look at this Cisco Community post that further describes this situation in more detail.
I have a short question. Letās say that I have a few geographically distinct sites that I want to enable connectivity between.
Which option is generally better? Configuring IPSec VPNs or purchasing an MPLS service from the service provider?
Ever since my CCNA studies, Iāve been wondering in what situations IPSec VPNs over the Internet would be more preferable than MPLS.
What are some things that we should take into consideration here, please? On what basis should we decide whether we want MPLS or IPSec VPNs or even our own dedicated connection (leased line) to connect our various sites?
As with many of these choices, it primarily comes down to a balance between service and cost. If you only have a few sites, and each site has few users, then cost-wise, itās preferable to use IPSec VPNs. If you have many sites with many users and you need a high level of administration and coordination to set all of this up, then it would probably cost less to go with a service providerās offering of MPLS since you wonāt have to deal with configuration and maintenance.
These are the two extremes. However, additional characteristics that you should take into account for each case include:
IPSec VPNs
Theyāre free (assuming you already have the Internet connection and the appropriate equipment)
They can be set up and torn down by you or your staff so you have full control
Theyāre typically easy to set up and manage, assuming you have a small number of sites.
MPLS
Itās a service you typically have to purchase from a provider, so there is a cost
Itās a black box for you so you donāt have to configure anything, itās all taken care of by the service provider
Both choices are safe and typically will provide you with what you need. However, you should also consider other options as well including:
DMVPN
FlexVPN
SD-WAN
Leased lines are very rare today because they are very expensive (since they require a dedicated circuit) and because other WAN technologies such as those mentioned are much more flexible.
I hope this gives you an overview of the kinds of things you should keep in mind when choosing a WAN technology for your particular scenario.