While I am sure that it made it easier to create the example I am sorry that your reference used 100 as both the ACL number and the crypto map sequence number, since it makes it more difficult to see clearly the relationship. The crypto map needs a sequence number which it uses to order the instances within the crypto map (if the map has more than one instance). The crypto sequence number has no other significance and does not NEED to match anything else. Any matching would be a matter of convenience.
I will suggest an approach slightly different from the one suggested by Cathy. She suggested two crypto maps. Since you need to assign the crypto map to the outbound interface and I am not sure that you have more than one outbound interface I will suggest that you create one crypto map with two instances:
crypto map to_remote 10 ipsec-isakmp
set peer 126.96.36.199
set transform-set to_vpn
match address 101
crypto map to_remote 20 ipsec-isakmp
set peer 188.8.131.52
set transform-set to_vpn
match address 102
In this case it should be a bit more obvious that the match address 101 and match address 102 are matching access lists which you will create. In access list 101 you will be permitting traffic with source of your local lan and destination of the remote lan at the first remote site (with an access list mask that will uniquely identify the remote lan). To facilitate site to site traffic you would also need to permit traffic with source of site 2 and destinatin of site 1. In access list 102 you will be permitting traffic with source of your local lan and destination of the remote lan at the second site (wit an access list mask that will uniquely identify the remote lan). To facilitate site to site traffic you would also need to permit traffic with source of site 1 and destination of site 2. (Since both remote LANs are /27 the mask you need in the access list is 0.0.0.15 which will match a /27 subnet and allow you to uniquely identify each remote.)
The crypto maps at the remote site will need only a single instance of their crypto map. Their access list should be the inverse of the corresponding access list at the central site.
My answer of 0.0.0.15 was not correct. I am not sure whether I incorrectly remembered the mask you are using or if I just made a mental mistake. the mask of 0.0.0.15 would have been correct if you were using a /28. For a /27 the correct mask for the access list would be 0.0.0.31.
The logic explained in the link you posted is exactly right. You take the subnet mask and invert the 1s and 0s. So your subnet mask of 224 becomes a filter mask of 31.
You may not be very experienced about access lists but this time you very correctly identified my mistake.
I've been talking this over with some other people and here is what we were wondering:
Since all traffic is going to be encrypted between the remote sites and the main site - internet and all other traffic will be routed and filtered at the main site - can't we get by with a very simple ACL?
Maybe something like:
access-list 101 permit ip 172.31.2.32 0.0.0.31 any, and then the inverse going back out to the remote site?
Since the vpn router will be sitting between our border router and also getting filtered through a PIX (before touching the rest of the internal network), can we rely on those to provide our protection?
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :