Wednesday, August 2, 2017

VPN – asymmetric traffic

Recently I worked on one problem related with asymmetric VPN traffic. It was caused by misconfiguration of encryption domain. We fixed the problem and I would like to document the scenario. My previous post is about my first python script which helped to find issues, more details here.

This is a scenario I will work with:



[rA]g0/1-------g0/2[asaC]g0/1-----------g0/1[asaD]g0/2-------g0/1[rB]

                      |      VPN TUNNEL       |
                       ========================

10.1.0.2 -  10.1.0.1[ ]10.0.0.1       10.0.0.2[ ]10.2.0.1 - 10.2.0.2

LAN1:                                                          LAN2:
10.1.1.0/24                                              10.2.1.0/24
10.1.2.0/24                                              10.2.2.0/24
 
 
 
 
Traffic from 10.1.1.0/24 and 10.1.2.0/24 should go through VPN tunnel set up between two ASAs: ‘asaC’ and ‘asaD’

This is an access list I created. They were implemented in the same way (order too!). As you see there are many overlapping entries (host are overlapped by subnets, subnets are overlapped by another subnets):


object network 10.1.2.1
 host 10.1.2.1
object network 10.1.2.0_24
 subnet 10.1.2.0 255.255.255.0
object network 10.1.0.0_16
 subnet 10.1.0.0 255.255.0.0

object network 10.2.2.1
 host 10.2.2.1
object network 10.2.2.0_24
 subnet 10.2.2.0 255.255.255.0
object network 10.2.0.0_16
 subnet 10.2.0.0 255.255.0.0

object-group network LAN1
 network-object host 10.1.1.1
 network-object 10.1.1.0 255.255.255.0
 network-object object 10.1.2.1
 network-object object 10.1.2.0_24
 network-object object 10.1.0.0_16

object-group network LAN2
 network-object host 10.2.1.1
 network-object 10.2.1.0 255.255.255.0
 network-object object 10.2.2.1
 network-object object 10.2.2.0_24
 network-object object 10.2.0.0_16
 
 
The only one difference is the order:

on asaC there is:

 access-list ACL extended permit ip object-group LAN1 object-group LAN2
  
on asaD:
 
 
access-list ACL extended permit ip object-group LAN2 object-group LAN1 
 

With above configuration VPN works fine.

When on one end (asaC) the order of access list is changed, for example ‘network-object host 10.1.1.1’ is moved as last item in ‘object-group network LAN1’ we can see asymmetric traffic:


object-group network LAN1
 network-object 10.1.1.0 255.255.255.0
 network-object object 10.1.2.1
 network-object object 10.1.2.0_24
 network-object object 10.1.0.0_16
 network-object host 10.1.1.1      <- this one was moved from first position
 
 
Traffic is sent from router A and it can’t pass through:
 
 
rA#ping 10.2.1.1 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
.....
Success rate is 0 percent (0/5)
rA#
 
 
On asaC we can see SA between: 10.1.1.0/24 and 10.2.1.1/32 (first match) but traffic goes only in one direction (4 encaps and 0 decaps packets)
 
 
asaC# sh crypto ipsec sa
interface: outside
 Crypto map tag: CM, seq num: 1, local addr: 10.0.0.1

access-list ACL extended permit ip 10.1.1.0 255.255.255.0 host 10.2.1.1
 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
 remote ident (addr/mask/prot/port): (10.2.1.1/255.255.255.255/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
 
 
ACL is processed top-down and first one which matches the source and destination IPs is:
 
 
asaC# sh access-list ACL
access-list ACL; 25 elements; name hash: 0xdd71d952
access-list ACL line 1 extended permit ip object-group LAN1 object-group LAN2 (hitcnt=3) 0x6d84ee8e
 access-list ACL line 1 extended permit ip 10.1.1.0 255.255.255.0 host 10.2.1.1 (hitcnt=3) 0x2baae81e
 access-list ACL line 1 extended permit ip 10.1.1.0 255.255.255.0 10.2.1.0 255.255.255.0 (hitcnt=0) 0x847a74cc
 
 
On asaD: 10.2.1.1/32 and 10.1.1.0 as well
 
 
asaD# sh crypto ipsec sa
interface: outside
 Crypto map tag: CM, seq num: 1, local addr: 10.0.0.2

access-list ACL extended permit ip host 10.2.1.1 10.1.1.0 255.255.255.0
 local ident (addr/mask/prot/port): (10.2.1.1/255.255.255.255/0/0)
 remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
 current_peer: 10.0.0.1




#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
 
 
 
but looking at ACL counters we can see the problem. The traffic matches different entry (host – host) which was taken as a first match (top down search):
 
 
asaD# sh access-list ACL
access-list ACL; 25 elements; name hash: 0xdd71d952
access-list ACL line 1 extended permit ip object-group LAN2 object-group LAN1 (hitcnt=4) 0x895799c9
 access-list ACL line 1 extended permit ip host 10.2.1.1 host 10.1.1.1 (hitcnt=4) 0x308a3f4d
 access-list ACL line 1 extended permit ip host 10.2.1.1 10.1.1.0 255.255.255.0 (hitcnt=1) 0x439f8c91
 
 
When we change direction and now router B initiate traffic it looks fine:
Router B:


rB#ping 10.1.1.1 source 10.2.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 10.2.1.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms

rB#
 
 
 
SA is defined by ACL entry: host – host (10.2.1.1-10.1.1.1)
 
 
 
asaD# sh crypto ipsec sa

interface: outside

    Crypto map tag: CM, seq num: 1, local addr: 10.0.0.2




      access-list ACL extended permit ip host 10.2.1.1 host 10.1.1.1

      local ident (addr/mask/prot/port): (10.2.1.1/255.255.255.255/0/0)

      remote ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/0/0)

      current_peer: 10.0.0.1







      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
 
 
 
 
what is the first match:
 
  
 
 
asaD# sh access-list ACL

access-list ACL; 25 elements; name hash: 0xdd71d952

access-list ACL line 1 extended permit ip object-group LAN2 object-group LAN1 (hitcnt=3) 0x895799c9

  access-list ACL line 1 extended permit ip host 10.2.1.1 host 10.1.1.1 (hitcnt=3) 0x308a3f4d
 
 
 
 
On asaC SA is created based on ACL: network-host (10.1.1.0/24 and 10.2.1.2):
 
 
 
 
asaC# sh crypto ipsec sa

interface: outside

    Crypto map tag: CM, seq num: 1, local addr: 10.0.0.1




      access-list ACL extended permit ip 10.1.1.0 255.255.255.0 host 10.2.1.1

      local ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/0/0)

      remote ident (addr/mask/prot/port): (10.2.1.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
 
 
 
and the same ACL has hits:
 
 
asaC# sh access-list ACL

access-list ACL; 25 elements; name hash: 0xdd71d952

access-list ACL line 1 extended permit ip object-group LAN1 object-group LAN2 (hitcnt=1) 0x6d84ee8e

  access-list ACL line 1 extended permit ip 10.1.1.0 255.255.255.0 host 10.2.1.1 (hitcnt=1) 0x2baae81e
 
 
 
The 2nd scenario also contains differences between devices but traffic can pass through. Definition of encryption domain can’t contain any overlapping entries. When the same IP is matched by more than one entry it may cause problem like this described above. Traffic from right to left (rB->rA) can’t pass through but from right to left (rA->rB) can. All access lists should be reviewed and modified if necessary. To speed the process of reviewing ACLs I wrote a script in python which automate the reviewing process.
 

No comments:

Post a Comment