Skip to main content

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

Today I’d like to test ikev2 on ASA (PKI) and check some settings of the tunnel. I have 2 ASA as per below diagram. I set terminal enrolment to present how to install certificate manually without SCEP (Simple Certificate Enrollment Protocol). I have to set up the tunnel to allow following server to communicate:
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
I’m not allowed to accept traffic between other hosts.

        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 start:

ASA1:

!
hostname asa1
domain-name test.com
!
interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 10.0.0.1 255.255.255.0
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 11.11.11.1 255.0.0.0
!

ASA2:

!
hostname asa2
domain-name test.com
!
interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 10.0.0.2 255.255.255.0
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 20.0.0.2 255.0.0.0
!

Access list to catch match traffic:

ASA1:
 
access-list VPN extended permit ip host 11.11.11.11 host 20.0.0.1
access-list VPN extended permit ip host 11.11.12.12 host 20.0.2.2
access-list VPN extended permit ip host 11.11.13.13 host 20.0.3.3

ASA2:
 
access-list VPN extended permit ip host 20.0.0.1 host 11.11.11.11
access-list VPN extended permit ip host 20.0.2.2 host 11.11.12.12
access-list VPN extended permit ip host 20.0.3.3 host 11.11.13.13 

Ikev2 policy:
 
crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 5
 prf sha256
 lifetime seconds 86400

crypto ikev2 enable outside

IPsec proposals:

crypto ipsec ikev2 ipsec-proposal IPSEC-PROPOSAL
 protocol esp encryption aes-256
 protocol esp integrity sha-1

Trustpoint:

crypto ca trustpoint PKI-TRUSTPOINT
 enrollment terminal
 keypair KEY1024
 crl configure

Tunnel group for ASA1:

tunnel-group 10.0.0.2 type ipsec-l2l
tunnel-group 10.0.0.2 ipsec-attributes
 ikev2 remote-authentication certificate
 ikev2 local-authentication certificate PKI-TRUSTPOINT
!

and for ASA2:

tunnel-group 10.0.0.1 type ipsec-l2l
tunnel-group 10.0.0.1 ipsec-attributes
 ikev2 remote-authentication certificate
 ikev2 local-authentication certificate PKI-TRUSTPOINT
!

For PKI we need to enable NTP to be sure the clocks are synchronized:

ntp server 10.0.0.100

and last thing is routing:

ASA1:

route inside 11.11.0.0 255.255.0.0 11.11.11.11 1
route outside 20.0.0.0 255.255.0.0 10.0.0.2 1

ASA2:

route outside 11.11.0.0 255.255.0.0 10.0.0.1 1
route inside 20.0.0.0 255.255.0.0 20.0.0.1 1

PKI Server configuration:

!
hostname r3
!
ip domain name test.com
!
crypto pki server PKI-SERVER
 issuer-name CN=r3.test.com,OU=IT
 grant auto
 hash sha256
!
ip http server
!
ntp master
! 

Don’t forget to enable the PKI server:

r3(cs-server)#no shut
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password:

Re-enter password:
% Generating 1024 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 2 seconds)
% Exporting Certificate Server signing certificate and keys...

% Certificate Server enabled.
r3(cs-server)#
May 10 00:29:16.127: %SSH-5-ENABLED: SSH 1.99 has been enabled
r3(cs-server)#
May 10 00:29:16.519: %PKI-6-CS_ENABLED: Certificate server now enabled.
r3(cs-server)#

I will check now the basic connectivity:

r2#ping 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/40/72 ms
r2#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/62/76 ms
r2#

r1#ping 11.11.11.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.11.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/29/56 ms
r1#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/74/108 ms
r1#

Ok, everything works fine. Let’s start the enrollment process:

1) Export CA certificate from PKI server

r3(config)#crypto pki export PKI-SERVER pem terminal
% The specified trustpoint is not enrolled (PKI-SERVER).
% Only export the CA certificate in PEM format.
% CA certificate:
-----BEGIN CERTIFICATE-----
MIICHzCCAYigAwIBAgIBATANBgkqhkiG9w0BAQsFADAjMQswCQYDVQQLEwJJVDEU
MBIGA1UEAxMLcjMudGVzdC5jb20wHhcNMTQwNTEwMDAyOTE2WhcNMTcwNTA5MDAy
OTE2WjAjMQswCQYDVQQLEwJJVDEUMBIGA1UEAxMLcjMudGVzdC5jb20wgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAK9p2yJJ2lR/sEhoekAdObEWCCLJhWqDjjC+
Mmpd6VU03kkobmkRRnk5Bj3HBBRmrKDKsu8ENFFObJUOxv6ZioAmk/x5dZhtkH9q
98nEUmWLXUUzCYr7s3P7X2svLapzg0q8xiC3EZJlkAU0Jd7Q+4+mY8slbYXfLA/u
prA+4gyxAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgGG
MB8GA1UdIwQYMBaAFCt25LnKV4LBmSiTsK7sLhYr0cSfMB0GA1UdDgQWBBQrduS5
yleCwZkok7Cu7C4WK9HEnzANBgkqhkiG9w0BAQsFAAOBgQALFnar+jdDcg70D4eX
2YmsYxPc2dMzGu2EkJtXVssvFiKtS83zIkTLewhnnh8Mm7RQHkxhRsVgeH0PZtsl
2X9SY46xnQKvas6odbae1RPDsHjzR3MvNVIsEEElMP7B6mGvQpJyQ6UZh/J6eXGE
o2bK85Ldl85sMy9SUX5LxFYVCA==
-----END CERTIFICATE-----

r3(config)#

2) Install CA certificate on ASA1 and ASA2

asa1(config)# crypto ca authenticate PKI-TRUSTPOINT
Enter the base 64 encoded CA certificate.
End with the word "quit" on a line by itself
-----BEGIN CERTIFICATE-----
MIICHzCCAYigAwIBAgIBATANBgkqhkiG9w0BAQsFADAjMQswCQYDVQQLEwJJVDEU
MBIGA1UEAxMLcjMudGVzdC5jb20wHhcNMTQwNTEwMDAyOTE2WhcNMTcwNTA5MDAy
OTE2WjAjMQswCQYDVQQLEwJJVDEUMBIGA1UEAxMLcjMudGVzdC5jb20wgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAK9p2yJJ2lR/sEhoekAdObEWCCLJhWqDjjC+
Mmpd6VU03kkobmkRRnk5Bj3HBBRmrKDKsu8ENFFObJUOxv6ZioAmk/x5dZhtkH9q
98nEUmWLXUUzCYr7s3P7X2svLapzg0q8xiC3EZJlkAU0Jd7Q+4+mY8slbYXfLA/u
prA+4gyxAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgGG
MB8GA1UdIwQYMBaAFCt25LnKV4LBmSiTsK7sLhYr0cSfMB0GA1UdDgQWBBQrduS5
yleCwZkok7Cu7C4WK9HEnzANBgkqhkiG9w0BAQsFAAOBgQALFnar+jdDcg70D4eX
2YmsYxPc2dMzGu2EkJtXVssvFiKtS83zIkTLewhnnh8Mm7RQHkxhRsVgeH0PZtsl
2X9SY46xnQKvas6odbae1RPDsHjzR3MvNVIsEEElMP7B6mGvQpJyQ6UZh/J6eXGE
o2bK85Ldl85sMy9SUX5LxFYVCA==
-----END CERTIFICATE-----
quit

INFO: Certificate has the following attributes:
Fingerprint:     2316af3a ac527e88 f7845632 589decda
Do you accept this certificate? [yes/no]:

Before you respond you can check if the fingerprints match:

r3#sh crypto pki certificates verbose  | i Finger
  Fingerprint MD5: 2316AF3A AC527E88 F7845632 589DECDA
  Fingerprint SHA1: FE5DE9D1 2B55DF24 8634CA8E 89DC83C3 F0D107C8
r3#

we see the fingerprints are the same, so we can respond ‘yes’:

Do you accept this certificate? [yes/no]: yes

Trustpoint CA certificate accepted.

% Certificate successfully imported
asa1(config)#

3) Generate Certificate Request:

asa1(config)# crypto ca enroll PKI-TRUSTPOINT
% Start certificate enrollment ..

% The fully-qualified domain name in the certificate will be: asa1.test.com

% Include the device serial number in the subject name? [yes/no]: no

Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:
-----BEGIN CERTIFICATE REQUEST-----
MIIBmTCCAQICAQAwHjEcMBoGCSqGSIb3DQEJAhYNYXNhMS50ZXN0LmNvbTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsnJKpNSUPcz3u41xuqxYJy+j2QtiaWni
kLyvhH0090qF+fsBOfCQjyWp4cw5l2upx9zAGScUiISbb/m4jg4BDtuUuG+PqFDl
x8xX7AdsVzci4Z6gYNZOfnnL9TKg/YwHl9VNKdwCwsZMafEiBIBgjDYH+EH0+Hfp
1TM7R4GCLn0CAwEAAaA7MDkGCSqGSIb3DQEJDjEsMCowDgYDVR0PAQH/BAQDAgWg
MBgGA1UdEQQRMA+CDWFzYTEudGVzdC5jb20wDQYJKoZIhvcNAQEFBQADgYEAnNZ6
RN8cVnQQG6TGBeoxFZL49d7dp9ECM/XZNmjD7k4vsPS+6p8p9UMCI3od5o0Z5mfx
a47Bd34RS66YcZQiJTJ5dh+v/ve6p321Q5I0E0OBEZTXRZeRmGDZ5vgPZoSMkUwd
+HvG5+yKmQ8uoHNsqCyE3QjENFycwl/Fe03CguY=
-----END CERTIFICATE REQUEST-----

Redisplay enrollment request? [yes/no]:

4) Request the certificate from PKI server

r3#crypto pki server PKI-SERVER request pkcs10 terminal base64
PKCS10 request in base64 or pem

% Enter Base64 encoded or PEM formatted PKCS10 enrollment request.
% End with a blank line or "quit" on a line by itself.
-----BEGIN CERTIFICATE REQUEST-----
MIIBmTCCAQICAQAwHjEcMBoGCSqGSIb3DQEJAhYNYXNhMS50ZXN0LmNvbTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsnJKpNSUPcz3u41xuqxYJy+j2QtiaWni
kLyvhH0090qF+fsBOfCQjyWp4cw5l2upx9zAGScUiISbb/m4jg4BDtuUuG+PqFDl
x8xX7AdsVzci4Z6gYNZOfnnL9TKg/YwHl9VNKdwCwsZMafEiBIBgjDYH+EH0+Hfp
1TM7R4GCLn0CAwEAAaA7MDkGCSqGSIb3DQEJDjEsMCowDgYDVR0PAQH/BAQDAgWg
MBgGA1UdEQQRMA+CDWFzYTEudGVzdC5jb20wDQYJKoZIhvcNAQEFBQADgYEAnNZ6
RN8cVnQQG6TGBeoxFZL49d7dp9ECM/XZNmjD7k4vsPS+6p8p9UMCI3od5o0Z5mfx
a47Bd34RS66YcZQiJTJ5dh+v/ve6p321Q5I0E0OBEZTXRZeRmGDZ5vgPZoSMkUwd
+HvG5+yKmQ8uoHNsqCyE3QjENFycwl/Fe03CguY=
-----END CERTIFICATE REQUEST-----
quit

and we see the new certificate has been granted (grant auto !):

% Granted certificate:
MIICIzCCAYygAwIBAgIBAjANBgkqhkiG9w0BAQsFADAjMQswCQYDVQQLEwJJVDEU
MBIGA1UEAxMLcjMudGVzdC5jb20wHhcNMTQwNTEwMDA0MzI0WhcNMTUwNTEwMDA0
MzI0WjAeMRwwGgYJKoZIhvcNAQkCFg1hc2ExLnRlc3QuY29tMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQCyckqk1JQ9zPe7jXG6rFgnL6PZC2JpaeKQvK+EfTT3
SoX5+wE58JCPJanhzDmXa6nH3MAZJxSIhJtv+biODgEO25S4b4+oUOXHzFfsB2xX
NyLhnqBg1k5+ecv1MqD9jAeX1U0p3ALCxkxp8SIEgGCMNgf4QfT4d+nVMztHgYIu
fQIDAQABo2wwajAYBgNVHREEETAPgg1hc2ExLnRlc3QuY29tMA4GA1UdDwEB/wQE
AwIFoDAfBgNVHSMEGDAWgBQrduS5yleCwZkok7Cu7C4WK9HEnzAdBgNVHQ4EFgQU
DHLI79JaeMSRnyXLSZJ5sX2itbgwDQYJKoZIhvcNAQELBQADgYEAXlS4lkVagJhe
lAkDTSLTPOQEbUImvulGYcuBKf9nThZlIcF3OG1wtGLPekF1xlPkT6Rrtj2t3Osh
ggNlDNHycpwljMjzxz2DxqgTKkTa+gHUWS9E0JxlUx/ru1f9iNldUGimzUAzFKw1
tGh49lK2vcRgMnze12XMKR+R9y7in/c=

5) Install the certificate on ASAs:

asa1(config)# crypto ca import PKI-TRUSTPOINT certificate

% The fully-qualified domain name in the certificate will be: asa1.test.com


Enter the base 64 encoded certificate.
End with the word "quit" on a line by itself

MIICIzCCAYygAwIBAgIBAjANBgkqhkiG9w0BAQsFADAjMQswCQYDVQQLEwJJVDEU
MBIGA1UEAxMLcjMudGVzdC5jb20wHhcNMTQwNTEwMDA0MzI0WhcNMTUwNTEwMDA0
MzI0WjAeMRwwGgYJKoZIhvcNAQkCFg1hc2ExLnRlc3QuY29tMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQCyckqk1JQ9zPe7jXG6rFgnL6PZC2JpaeKQvK+EfTT3
SoX5+wE58JCPJanhzDmXa6nH3MAZJxSIhJtv+biODgEO25S4b4+oUOXHzFfsB2xX
NyLhnqBg1k5+ecv1MqD9jAeX1U0p3ALCxkxp8SIEgGCMNgf4QfT4d+nVMztHgYIu
fQIDAQABo2wwajAYBgNVHREEETAPgg1hc2ExLnRlc3QuY29tMA4GA1UdDwEB/wQE
AwIFoDAfBgNVHSMEGDAWgBQrduS5yleCwZkok7Cu7C4WK9HEnzAdBgNVHQ4EFgQU
DHLI79JaeMSRnyXLSZJ5sX2itbgwDQYJKoZIhvcNAQELBQADgYEAXlS4lkVagJhe
lAkDTSLTPOQEbUImvulGYcuBKf9nThZlIcF3OG1wtGLPekF1xlPkT6Rrtj2t3Osh
ggNlDNHycpwljMjzxz2DxqgTKkTa+gHUWS9E0JxlUx/ru1f9iNldUGimzUAzFKw1
tGh49lK2vcRgMnze12XMKR+R9y7in/c=
quit
INFO: Certificate successfully imported
asa1(config)#

As we see the certificate has been successfully imported.

asa1# sh crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 02
  Certificate Usage: General Purpose
  Public Key Type: RSA (1024 bits)
  Signature Algorithm: SHA256 with RSA Encryption
  Issuer Name:
    cn=r3.test.com
    ou=IT
  Subject Name:
    hostname=asa1.test.com
  Validity Date:
    start date: 00:43:24 UTC May 10 2014
    end   date: 00:43:24 UTC May 10 2015
  Associated Trustpoints: PKI-TRUSTPOINT

CA Certificate
  Status: Available
  Certificate Serial Number: 01
  Certificate Usage: Signature
  Public Key Type: RSA (1024 bits)
  Signature Algorithm: SHA256 with RSA Encryption
  Issuer Name:
    cn=r3.test.com
    ou=IT
  Subject Name:
    cn=r3.test.com
    ou=IT
  Validity Date:
    start date: 00:29:16 UTC May 10 2014
    end   date: 00:29:16 UTC May 9 2017
  Associated Trustpoints: PKI-TRUSTPOINT

asa1#

Repeat the same steps for ASA2.

Ok, now we can start sending some traffic from R1 to R2. Let’s check first if traffic not listed below is denied:

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

We see the traffic is not allowed (as expected):

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#ping 20.0.2.2 source 11.11.11.11
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.11.11
.....
Success rate is 0 percent (0/5)
r1#

Now I send valid traffic:

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 80 percent (4/5), round-trip min/avg/max = 56/102/136 ms
r1#

Let’s check the tunnel:

asa1# sh crypto ikev2 sa

IKEv2 SAs:

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

Tunnel-id                 Local                Remote     Status         Role
260373857          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/7 sec
Child sa: local selector  11.11.11.11/0 - 11.11.11.11/65535
          remote selector 20.0.0.1/0 - 20.0.0.1/65535
          ESP spi in/out: 0xd6b22b77/0xb7edd7f8
asa1#
asa1#


We see the tunnel is up and the ASA1 role is an initiator. The same command with ‘detail’ option shows us much more details about the tunnel:

asa1# sh crypto ikev2 sa detail

IKEv2 SAs:

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

Tunnel-id                 Local                Remote     Status         Role
260373857          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/15 sec
      Session-id: 5
      Status Description: Negotiation done
      Local spi: F4E4362133A49D40       Remote spi: 5EC1B493116D05FB
      Local id: hostname=asa1.test.com
      Remote id: hostname=asa2.test.com
      Local req mess id: 2              Remote req mess id: 0
      Local next mess id: 2             Remote next mess id: 0
      Local req queued: 2               Remote req queued: 0
      Local window: 1                   Remote window: 1
      DPD configured for 10 seconds, retry 2
      NAT-T is not detected
Child sa: local selector  11.11.11.11/0 - 11.11.11.11/65535
          remote selector 20.0.0.1/0 - 20.0.0.1/65535
          ESP spi in/out: 0xd6b22b77/0xb7edd7f8
          AH spi in/out: 0x0/0x0
          CPI in/out: 0x0/0x0
          Encr: AES-CBC, keysize: 256, esp_hmac: SHA96
          ah_hmac: None, comp: IPCOMP_NONE, mode tunnel

Now, I check IPsec tunnel:

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 host 11.11.11.11 host 20.0.0.1
      local ident (addr/mask/prot/port): (11.11.11.11/255.255.255.255/0/0)
      remote ident (addr/mask/prot/port): (20.0.0.1/255.255.255.255/0/0)
      current_peer: 10.0.0.2

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
      #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: B7EDD7F8
      current inbound spi : D6B22B77

    inbound esp sas:
      spi: 0xD6B22B77 (3602000759)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 126976, crypto-map: MAPA
         sa timing: remaining key lifetime (kB/sec): (4285439/28777)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x0000001F
    outbound esp sas:
      spi: 0xB7EDD7F8 (3085817848)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 126976, crypto-map: MAPA
         sa timing: remaining key lifetime (kB/sec): (4147199/28777)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

asa1#

We can notice the number of packets is correct, we lost only first ping:

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

When the tunnel is up, the traffic is allowed only between following hosts/networks:

asa1# sh crypto ipsec sa | i ident
      local ident (addr/mask/prot/port): (11.11.11.11/255.255.255.255/0/0)
      remote ident (addr/mask/prot/port): (20.0.0.1/255.255.255.255/0/0)
asa1#

The current settings are ok when we have only small number of hosts or servers. In huge networks with tens or hundreds servers, we can’t manage the ACL effectively. Let’s change the ACL ‘VPN’ and instead of three entries add only one:

ASA1:

no access-list VPN extended permit ip host 11.11.11.11 host 20.0.0.1
no access-list VPN extended permit ip host 11.11.12.12 host 20.0.2.2
no access-list VPN extended permit ip host 11.11.13.13 host 20.0.3.3

access-list VPN extended permit ip 11.11.0.0 255.255.0.0 20.0.0.0 255.255.0.0

ASA2:

access-list VPN extended permit ip 20.0.0.0 255.255.0.0 11.11.0.0 255.255.0.0

no access-list VPN extended permit ip host 20.0.0.1 host 11.11.11.11
no access-list VPN extended permit ip host 20.0.2.2 host 11.11.12.12
no access-list VPN extended permit ip host 20.0.3.3 host 11.11.13.13

and now test the tunnel again:

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 80 percent (4/5), round-trip min/avg/max = 60/108/232 ms
r1#

You can notice that now the traffic is allowed between all hosts.

asa1# sh crypto ipsec sa | i ident
      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)
asa1#

Is there any way to protect the traffic between specific hosts?
The answer is yes, we can apply vpn-filter to control the traffic. Let’s try to fix our security problem. I have to check first what group-policy is assigned to my tunnel-group:
 
asa1(config)# sh run all | b tunnel-group 10.0.0.2
tunnel-group 10.0.0.2 type ipsec-l2l
tunnel-group 10.0.0.2 general-attributes
 no accounting-server-group
 default-group-policy DfltGrpPolicy
tunnel-group 10.0.0.2 ipsec-attributes
 no ikev1 pre-shared-key
 peer-id-validate req
 no chain
 no ikev1 trust-point
 isakmp keepalive threshold 10 retry 2
 ikev2 remote-authentication certificate
 ikev2 local-authentication certificate PKI-TRUSTPOINT
!

Ok, we see the ‘default-group-policy DfltGrpPolicy’. Let’s check how to set the vpn-filter:

asa1(config)# sh run all | b group-policy DfltGrpPolicy
group-policy DfltGrpPolicy internal
group-policy DfltGrpPolicy attributes
 banner none
 wins-server none
 dns-server none
 dhcp-network-scope none
 vpn-access-hours none
 vpn-simultaneous-logins 3
 vpn-idle-timeout 30
 vpn-session-timeout none
 vpn-filter none
 ipv6-vpn-filter none
 vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-clientless

There are many parameters but I concentrate only on ‘vpn-filter none’. We have two options here. We can change the settings of the default group-policy or we can add a new one. I prefer the second option.

1) Add a new ACL but remember the source host/subnet means remote network and vice-versa. In my case the ACL for ASA1 should look like:

access-list VPN-FILTER extended permit ip host 20.0.0.1 host 11.11.11.11

2) New group policy

group-policy IKEV2-GROUP-POLICY internal
group-policy IKEV2-GROUP-POLICY attributes
vpn-filter value VPN-FILTER

3) and then we have to set the new group-policy in my tunnel-group:
 
tunnel-group 10.0.0.2 general-attributes
 default-group-policy IKEV2-GROUP-POLICY

Now, let’s clear the existing tunnel and do some tests:
 
asa1# clear crypto ikev2 sa
asa1# clear crypto ipsec sa

I start with valid hosts’ pairs:
 
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 80 percent (4/5), round-trip min/avg/max = 60/86/152 ms
r1#

As we see the tunnel is up, let’s check my new access-list

asa1# sh access-list  | i VPN-FILTER
access-list VPN-FILTER; 1 elements; name hash: 0x99573b1c
access-list VPN-FILTER line 1 extended permit ip host 20.0.0.1 host 11.11.11.11 (hitcnt=5) 0x7ec54c79
asa1#

Now, I try to send traffic which was previously allowed:

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 0 percent (0/5)
r1#

so, the tunnel is up but the traffic is blocked. The filter controls the traffic also from the second peer:

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

You should remember that traffic blocked by vpn-filter can initiate the tunnel if its source and destination are within ACL proxy range.

Let’s complete the configuration to have the same policy as I had in my first version:

access-list VPN-FILTER extended permit ip host 20.0.2.2 host 11.11.12.12
access-list VPN-FILTER extended permit ip host 20.0.3.3 host 11.11.13.13
access-list VPN-FILTER extended deny ip any any log

Before test clear the tunnel.

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 = 60/64/76 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/77/100 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 80 percent (4/5), round-trip min/avg/max = 64/80/120 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 0 percent (0/5)

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 0 percent (0/5)
r1#

As we see above, the traffic between hosts is working as before. The vpn-filter blocks non-allowed pings. The situation is more complicated when you have NAT implemented but it will be the topic for next post.

Comments

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an

MAC Authentication Bypass

One of the method to control your network is using MAB feature. It is helpful in case you have devices without dot1x functionality. Today I will try to implement basic configuration and analyze log messages. There is only one switch SW1 and one device attached to port Fa1/0/2.   ! aaa new - model aaa authentication dot1x default group radius ! ! int Fas1 / 0 / 2 authentication host - mode single - host authentication port - control auto mab ! I haven’t configured ACS yet but let’s see what error message I receive:   SW1 ( config - if ) # mab - ev ( Fa1 / 0 / 2 ): Received MAB context create from AuthMgr mab - ev ( Fa1 / 0 / 2 ): Created MAB client context 0x1100000F mab : initial state mab_initialize has enter mab - ev ( Fa1 / 0 / 2 ): Sending create new context event to EAP from MAB for 0x1100000F ( 0000.0000 . 0000 ) mab - sm ( Fa1 / 0 / 2 ): Received event 'MAB_START' on handle 0x1100000F mab : during state mab_initia

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze the packet flo