ASA ikev2 VPN s-2-s (PKI) - part two

I’d like to continue the ikev2 topic (ASA ikev2 VPN s-2-s (PKI) - part one) and introduce new features which allow me to achieve the same result. I strongly recommend to read the previous post first to have a clear picture what I’m going to do. I will work on the same network diagram.

 11.11.11.0/24    10.0.0.0/24         20.0.0.0/24

  /----\ .11     .1 -----  .1      .2 -----  .2       .1/----\
 |  R1  |----------| ASA1 |----------| ASA2 |----------|  R2  |
  \----/            -----      |.100  -----             \----/
  Loop0                     /----\                       Loop0
11.11.12.12                |  R3  |                     20.0.2.2
  Loop1                     \----/                       Loop1
11.11.13.13               PKI SERVER                    20.0.3.3

Let’s remove the group-policy IKEV2-GROUP-POLICY from the tunnel-group.

asa1# conf t
asa1(config)# tunnel-group 10.0.0.2 general-attributes
asa1(config-tunnel-general)# no default-group-policy IKEV2-GROUP-POLICY
asa1(config-tunnel-general)#
asa1(config-tunnel-general)# end
asa1#

Repeat the same for ASA2. Now I check if the traffic between hosts is allowed:

r1#ping 20.0.0.1 source 11.11.13.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.13.13
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/76/108 ms

r1#ping 20.0.0.1 source 11.11.12.12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.12.12
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/64/76 ms

r1#ping 20.0.3.3 source 11.11.12.12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.3.3, timeout is 2 seconds:
Packet sent with a source address of 11.11.12.12
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/63/72 ms
r1#

As we see, even the traffic which we want to block is now allowed. Let’s remind the IP address list with permitted traffic:

a) 11.11.11.11 <-> 20.0.0.1

b) 11.11.12.12 <-> 20.0.2.2

c) 11.11.13.13 <-> 20.0.3.3

There is one global parameter which we can use to control the traffic in another way:

sysopt connection permit-ipsec

By default the command is active what means that ASA permits all traffic inside the VPN tunnel. You don’t need any access list to specify what is sent inside the tunnel. When you disable this feature “no sysopt connection permit-ipsec”, ASA requires access-list for all traffic which you want to send over the tunnel. Let’s disable the feature on both ASAs:

asa1(config)# no sysopt connection permit-vpn
asa2(config)# no sysopt connection permit-vpn

Let’s try if it works:

r1#ping 20.0.0.1 source 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
.....
Success rate is 0 percent (0/5)
r1#

As we see we can’t reach the destination but when we check the VPN connection we see it is active.

asa1# sh crypto ikev2 sa

IKEv2 SAs:

Session-id:23, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id                 Local                Remote     Status         Role
413441935          10.0.0.1/500          10.0.0.2/500      READY    INITIATOR
      Encr: AES-CBC, keysize: 256, Hash: SHA256, DH Grp:5, Auth sign: RSA, Auth verify: RSA
      Life/Active Time: 86400/1 sec
Child sa: local selector  11.11.0.0/0 - 11.11.255.255/65535
          remote selector 20.0.0.0/0 - 20.0.255.255/65535
          ESP spi in/out: 0x7680f345/0x48bb9d26
asa1#
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 11.11.0.0 255.255.0.0 20.0.0.0 255.255.0.0
      local ident (addr/mask/prot/port): (11.11.0.0/255.255.0.0/0/0)
      remote ident (addr/mask/prot/port): (20.0.0.0/255.255.0.0/0/0)
      current_peer: 10.0.0.2

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 10.0.0.1/500, remote crypto endpt.: 10.0.0.2/500
      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: 48BB9D26
      current inbound spi : 7680F345

    inbound esp sas:
      spi: 0x7680F345 (1988162373)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 200704, crypto-map: MAPA
         sa timing: remaining key lifetime (kB/sec): (3916800/28580)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0x48BB9D26 (1220255014)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 200704, crypto-map: MAPA
         sa timing: remaining key lifetime (kB/sec): (4147199/28580)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

asa1#

As you see the four packets were sent but they were dropped on the ASA2 outside interface:

asa1# sh crypto ipsec sa | i encrypt|decrypt
      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
asa1# 

I will add now a new access-list on the outside interface.

Remember that the access list should permit traffic coming from your peer:

ASA1:

access-list OUT extended permit icmp host 20.0.0.1 host 11.11.11.11
access-list OUT extended permit icmp host 20.0.2.2 host 11.11.12.12 
access-list OUT extended permit icmp host 20.0.3.3 host 11.11.13.13 
access-group OUT in interface outside

ASA2:

access-list OUT extended permit icmp host 11.11.11.11 host 20.0.0.1
access-list OUT extended permit icmp host 11.11.12.12 host 20.0.2.2
access-list OUT extended permit icmp host 11.11.13.13 host 20.0.3.3
access-group OUT in interface outside

and now check if we can ping:

r1#ping 20.0.0.1 source 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/71/80 ms

r1#ping 20.0.2.2 source 11.11.12.12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.2.2, timeout is 2 seconds:
Packet sent with a source address of 11.11.12.12
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/89/136 ms

r1#ping 20.0.3.3 source 11.11.13.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.3.3, timeout is 2 seconds:
Packet sent with a source address of 11.11.13.13
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/79/128 ms

As we see all servers (from my list) can communicate each other. The last thing is to check ‘non-allowed’ traffic:

r1#ping 20.0.3.3 source 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.3.3, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
.....
Success rate is 0 percent (0/5)
r1#

As we expected we can’t ping host from other group.

 
3
Kudos
 
3
Kudos

Now read this

GET VPN - part one

Today I would like to implement GET VPN solution based on following scenario: As you see there are many components like two key servers, CA server, three members and one firewall. I start the configuration with only one key server and... Continue →