I went back to IPSEC negotiation details and came up with this since we encountered several issues with our previous implementations regarding interesting traffic mismatch. So I browsed my books again to search for the details and here's what I found.
Step 3: Configure the Crypto ACL
An extended access list is used to determine interesting traffic. The access lists are shown in the
dashed circles. At the remote office, the access list is number 170, while at the central office, the
list is number 155. Each list defines the source and destination addresses of traffic that will travel
through the IPsec tunnels.
Usually, it is very important that the two lists be mirror images of each other. The source address in one
list must be the destination address in the other and vice versa. A standard access list cannot be used for
identifying interesting traffic because it does not have the ability to specify destination addresses.
It is also possible to simply have one site (say a remote site) send everything through an IPsec VPN
tunnel to the main site, yet the main site only sends traffic destined for that remote site through the
VPN. This makes the configuration at the remote site fairly simple, and isolates the more advanced
configuration to the main site.
NOTE Crypto access lists are sometimes called mirrored access lists. Each IPsec peer must
have an extended access list that indicates interesting traffic. At a minimum, this interesting
traffic must specify both source and destination IP addresses and can add protocols and ports for
From an IP addressing perspective, what is interesting to one site (source/destination) is exactly
opposite to the other site (destination/source). If one side indicates source/destination subnets as
interesting, then the other site must reverse the source/destination subnets for its interesting
traffic configuration. If one end uses subnets in the crypto ACL for source/destination and the
other end uses individual IP addresses for source/destination, the interesting traffic is not
mirrored and the IPsec tunnel will not work.
I am kinda confused with the explanation, it was mentioned on the second paragraph that on the remote site, it can be configured as permit ip any any as the interesting traffic to simplify the implementation then on the main site, it subnets can be used instead. That's how I understood it. But on the last paragraph, it was mentioned that a total mismatch of the ACL will make the IPSEC tunnel not work.
Are the ACLs being sent from one end to the other end? I don't think it is because of the differences on the firewall configurations. Like when we tried to establish a tunnel from an ASA firewall to a Netscreen where the configuration details are so different. But what resolved the issue is a mismatch ACL. They configured 10.0.0.0/8 as the source but we configured specific subnets of their 10.0.0.0/8 network as the destination. I'm wondering why the ACL can be the culprit in this type of situation when I think what's important is to identify which traffic should be sent through the tunnel.
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...