Do I need exactly the same ACEs in my ACLs?

ikev2-ACL.jpg

http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/vpn_site2site.html#wp1042401

You can find one statement under the above link: “Configure ACLs that mirror each other on both sides of the connection.”

The answer is: not really. Let’s test it: one peer has following encryption domain:

asa1# sh run access-list
access-list VPN extended permit ip 20.0.0.0 255.255.255.0 host 150.1.4.4
asa1#

one the second one:

R4(config-ext-nacl)#
R4(config-ext-nacl)#do sh runn | s access
ip access-list extended VPN
 permit ip 150.1.4.0 0.0.0.255 20.0.0.0 0.0.0.255
R4(config-ext-nacl)#

As you see the ACL on my ASA is more specific (host 150.1.4.4).

Before I initiate traffic let’s check the ipsec sessions:

R4#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: DOWN
Peer: 10.0.0.1 port 500
  IPSEC FLOW: permit ip 150.1.4.0/255.255.255.0 20.0.0.0/255.255.255.0
        Active SAs: 0, origin: crypto map

R4#

Now I generate traffic and as you see a new IPsec flow has been added:

R4#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 10.0.0.1 port 500
  IKEv2 SA: local 10.0.0.4/500 remote 10.0.0.1/500 Active
  IPSEC FLOW: permit ip host 150.1.4.4 20.0.0.0/255.255.255.0
        Active SAs: 2, origin: crypto map
  IPSEC FLOW: permit ip 150.1.4.0/255.255.255.0 20.0.0.0/255.255.255.0
        Active SAs: 0, origin: crypto map

R4#

to be clear I don’t have host 150.1.4.4 in my ACL:

R4#sh run | s acce
ip access-list extended VPN
 permit ip 150.1.4.0 0.0.0.255 20.0.0.0 0.0.0.255
R4#sh run | s acce

I tested one more scenario to be sure it works with different masks:

R4(config-ext-nacl)#permit ip 150.1.4.0 0.0.0.15 20.0.0.0 0.0.0.255

and on 2nd peer:

asa1# sh run access-list
access-list VPN extended permit ip 20.0.0.0 255.255.255.0 150.1.4.0 255.255.255.0
asa1#

Before I generate traffic let’s check the ikev2 sessions:

R4#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: DOWN
Peer: 10.0.0.1 port 500
  IPSEC FLOW: permit ip 150.1.4.0/255.255.255.240 20.0.0.0/255.255.255.0
        Active SAs: 0, origin: crypto map

R4#

Let’s test it:

R5#ping 150.1.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 72/86/92 ms
R5#

On the R4 we can see IPsec flow that matches with ACL:

R4#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 10.0.0.1 port 500
  IKEv2 SA: local 10.0.0.4/500 remote 10.0.0.1/500 Active
  IPSEC FLOW: permit ip 150.1.4.0/255.255.255.240 20.0.0.0/255.255.255.0
        Active SAs: 2, origin: crypto map

R4#

On ASA we see the same SA:

asa1# sh crypto ipsec sa
interface: outside
    Crypto map tag: MAPA, seq num: 10, local addr: 10.0.0.1

      access-list VPN extended permit ip 20.0.0.0 255.255.255.0 150.1.4.0 255.255.255.0
      local ident (addr/mask/prot/port): (20.0.0.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (150.1.4.0/255.255.255.240/0/0)
      current_peer: 10.0.0.4

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

It means the SA will be created from more specific crypto domain.

I tested it also the opposite case scenario (ASA has less specific ACL):

asa1# sh run access-list
access-list VPN extended permit ip 20.0.0.0 255.255.255.0 150.1.0.0 255.255.0.0
asa1#
R4#sh run | s access
ip access-list extended VPN
 permit ip 150.1.4.0 0.0.0.15 20.0.0.0 0.0.0.255
R4#

and it works in the same way:

asa1# sh crypto ipsec sa
interface: outside
    Crypto map tag: MAPA, seq num: 10, local addr: 10.0.0.1

      access-list VPN extended permit ip 20.0.0.0 255.255.255.0 150.1.0.0 255.255.0.0
      local ident (addr/mask/prot/port): (20.0.0.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (150.1.4.0/255.255.255.240/0/0)
      current_peer: 10.0.0.4

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

R4#sh crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: FastEthernet0/0
Uptime: 00:01:02
Session status: UP-ACTIVE
Peer: 10.0.0.1 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 10.0.0.1
      Desc: (none)
  IKEv2 SA: local 10.0.0.4/500 remote 10.0.0.1/500 Active
          Capabilities:(none) connid:1 lifetime:23:58:58
  IPSEC FLOW: permit ip 150.1.4.0/255.255.255.240 20.0.0.0/255.255.255.0
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 8 drop 0 life (KB/Sec) 4454585/3537
        Outbound: #pkts enc'ed 8 drop 0 life (KB/Sec) 4454585/3537

R4#
 
6
Kudos
 
6
Kudos

Now read this

DMVPN - phase two - OSPF

In my second post about DMVPN and OSPF I would like to change my configuration from my previous post to enable direct communication between spoke routers. I strongly recommend to read my previous post first before you start reading this... Continue →