Re: IPSEC Tunnel Interesting Traffic

jpl861 · ‎07-15-2010

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

Jitendriya Athavale · ‎07-17-2010

for IPSEC VPN mirror ACL is a requirement, as the identites are matched during the negotiation, you can verify this using debugs

schrothxx · ‎12-15-2010

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

jimmycher · ‎10-16-2019

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.