Skip to main content

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.
Labels:

Comments

Post a Comment

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 ...
8 comments
Read more

FortiGate and GRE tunnel

Recently I worked on one project where a client requested to re-route web traffic to the GRE tunnel to perform traffic inspection. I would like to share with you what is required if you configure it on FortiGate. We need a new GRE interface and policy base routing (PBR) to change the route for specific source IPs. Of course you need firewall policies to permit the traffic. Let's start with GRE interface. Unfortunately you can't configure it using the GUI, only CLI is the option: config system gre-tunnel edit "gre1" set interface "port1" set local-gw 55.55.55.55 set remote-gw 44.44.44.44 next end When the end peer is Cisco router, you need to set the IP for the GRE interface: config system interface edit gre1 set ip 192.168.10.10 255.255.255.255 set remote-ip192.168.10.20 end In next step we need to fix routing. We need the alternate path via GRE but to keep the route in the active routing table you need to set the same AD (adminis...
Post a Comment
Read more

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 ...
1 comment
Read more