07-15-2010 09:14 PM - edited 02-21-2020 04:44 PM
Hi,
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
additional detail.
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.
Any inputs will be appreciated. Thanks.
John
07-17-2010 07:36 AM
for IPSEC VPN mirror ACL is a requirement, as the identites are matched during the negotiation, you can verify this using debugs
12-15-2010 05:37 PM
There can be a mismatch of ACLs for interesting traffic between two IPSEC end-points. However, you will get odd and unpredictable routing and bugy access over the tunnel from time-to-time.
I often see clients I am asked to connect to that share out a /16 and we have some host IPs in that /16 in our statements.
Example.
router 1's intersting traffic ACL
permit ip 192.168.21.0 0.0.0.255 10.1.30.0 0.0.0.254
router 2's intersting traffic ACL
permit ip host 10.1.30.24 192.168.21.0 0.0.0.255
IP 10.1.30.24 will pass over the IPSEC tunnel thropugh these mismatched ACLs, but is a very sub optimal design for the following reasons:
1) Router 1 is leaving his subnet more open then needed.
2) If router 2 starts adding more host routes, I see very buggy things happen (like some hosts are unreachable).
Being that unpredictable things happen, I suggests following convention of matched ACL ..
Example
router 1's intersting traffic ACL
permit ip 192.168.21.0 0.0.0.255 host 10.1.30.24
router 2's intersting traffic ACL
permit ip host 10.1.30.24 192.168.21.0 0.0.0.255
10-16-2019 07:10 AM
I have a tunnel where the receiver is open to all ports, but the sender is only sending >UPD 1023. The tunnel comes up, but only when the receiver sends a ping. It does not come up when the sender sends UDP data.
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