when router get's ipsec packet does it look into crypto map acl

Question

So I have a question about IPSec.

For example, we have an extended ACL with one line 10.10.10.0/24 10.20.20.0/24 on one side (R1) and 10.20.20.0/24 10.10.10.0/24 on the other (R2).

When we see traffic coming from an encrypted channel what does the router perform first (besides correlating packet's SPI to a connection)?

I also have a hard time understanding the crypto map ACL part, do we look into it when we are getting IPSec traffic, and if we do, why there is only one line for 10.10.10.0 to 10.20.20.0 and no 10.20.20.0 to 10.10.10.0 for ingress traffic (R1)?

upd:

I was talking about ACL that is a part of crypto map probably it's because of my horrendous english. Here is the Cisco config:

int fa0/0
    ip 1.2.3.4
    crypto map myIPsecMap

crypto map myIPsecMap
    set transform-set ...
    match address myACL

myACL
    permit ip 10.10.10.0/24 10.20.20.0/24

When we send traffic from that router we check if it's from 10.10.10.0/24 and going to 10.20.20.0/24 then we crypt it (pure IPsec, no GRE), but when we are getting encrypted traffic i heard that we also look into that ACL (e.g. myACL) to check if it's from 10.20.20.0/24 and going to 10.10.10.0/24 (i guess it's more of a question about ACL rather than IPsec itself)

..

Ok, I checked it myself and indeed it does look in my ACL and if I dont add IP's on both sides Isakmp tunnel hangs on negotiating, i got it, for me it was very counterintuitive to think about ACL in that revesed way

I see how you were confused. Basically you create an ACL for the subnet(s) that you want to encrypt through the tunnel. Then you apply that ACL to a **crypto map**. Which is just a mapping of the ACL to an IPSec transform. Then you apply that crypto map to an interface. So that any time a packet is sent out that interface, it checks the ACL and encrypts with the associated IPSec parameters. — RoraΖ, Oct 20 '15 at 11:32

RoraΖ · Accepted Answer · 2015-10-20T11:41:36.427

The router needs to process the packet at the IP level. An encrypted packet has two different IPs. The gateway IPs that are creating the secure tunnel, and the real source/destination IPs to the private networks the tunnel is protecting.

It sees that traffic is coming in on an encrypted the channel, and it searches for a Security Association (SA) with the incoming source IP. If it finds an SA then the packet is decrypted, and then re-introduced into the network stack. The decrypted IP layer is then processed.

At this point is where any extended access control lists beyond the encrypted channel are applied because the source and destination addresses are now in the clear.

To explain how the config works you start with the myACL. You then create crypto map that contains the parameters that you want for your IPSec tunnel. The match address myACL simply means that traffic must match your rule for it to be encrypted. It maps the ACL to a set of IPSec parameters.

The last thing you do is apply the crypto map to an interface. This is what the crypto map myIPsecMap does. This tells the router, for any packet that is sent or received on this interface it must attempt to apply the crypto map. "Applying the crypto map" first checks against your ACL to see if the incoming or outgoing traffic matches. If it does it will apply the IPSec parameters outlined by myIPsecMap. If not it will continue on through the stack as normal.

when router get's ipsec packet does it look into crypto map acl

1 Answers1