cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 

ASA: Problemas de tráfico de VPN no siendo cifrado por ASP duplicados

Al momento de realizar troubleshooting del tráfico que va a través de un túnel de VPN, debemos verificar que los contadores

de paquetes cifrados y descifrados vayan incrementándose.

En algunas ocasiones podemos tener el problema de que el tráfico no esté siendo cifrado. Antes de correr los comandos

que se mencionan a continuación, deberemos revisar el nat, access-list del tráfico interesante, ruteo, o verificar

que no exista un crypto map con una prioridad mayor que esté haciendo un match al tráfico de este túnel.

Los siguientes comandos nos ayudarán a verificar si el tráfico no está siendo cifrado por un problema de ASP duplicados en el ASA.

a)      show asp table classi crypto

b)      show asp table vpn-context detail

c)       show cry ipsec sa peer 190.144.XX.YY

1) Primero revisamos el comando de show crypto ipsec sa peer x.x.x.x , para verificar si los contadores de paquetes encapsulados están o no aumentando.

ASA(config)# show cry ipsec sa peer 190.144.XX.YY

peer address: 190.144.XX.YY

    Crypto map tag: DYNIP-VPN, seq num: 5, local addr: 208.30.AA.BB

      local ident (addr/mask/prot/port): (10.10.144.0/255.255.254.0/0/0)

      remote ident (addr/mask/prot/port): (10.114.25.0/255.255.255.0/0/0)

      current_peer: 190.144.XX.YY

     #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0  ------------ Paquetes no siendo cifrados

      #pkts decaps: 760, #pkts decrypt: 760, #pkts verify: 760

      #pkts compressed: 0, #pkts decompressed: 0

      #pkts not compressed: 0, #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.: 208.30.AA.BB, remote crypto endpt.: 190.144.XX.YY

      path mtu 1500, ipsec overhead 58, media mtu 1500

      current outbound spi: 785E19A7

    inbound esp sas:

      spi: 0xB9EBADDA (3119230426)

         transform: esp-des esp-md5-hmac

         in use settings ={L2L, Tunnel, PFS Group 1, }

         slot: 0, conn_id: 15596, crypto-map: DYNIP-VPN

         sa timing: remaining key lifetime (sec): 1961

         IV size: 8 bytes

         replay detection support: Y

   outbound esp sas:

      spi: 0x785E19A7 (2019432871)

         transform: esp-des esp-md5-hmac

         in use settings ={L2L, Tunnel, PFS Group 1, }

         slot: 0, conn_id: 15596, crypto-map: DYNIP-VPN

         sa timing: remaining key lifetime (sec): 1961

         IV size: 8 bytes

         replay detection support: Y

2)Se deberá tomar el número en hexadecimal que aparece en el outbound SPI 0x785E19A7 y buscarlo en el comando de "show asp table vpn-context detail"

3) Se buscará el contexto en donde aparece este SPI

VPN CTX  = 0x1D5958BC ---- CONTEXTO

Pointer  = 0x026EEBF0

State    = UP

Flags    = ENCR+ESP

SA       = 0x0B343A5B

SPI      = 0x785E19A7

Group    = 0

Pkts     = 0

Bad Pkts = 0

Bad SPI  = 0

Spoof    = 0

Bad Crypto = 0

Rekey Pkt  = 0

Rekey Call = 0

4) Después de localizar el contexto asociado al SPI, se usa el número del contexto 0x1D5958BC y se buscan los asp de salida en el show asp table classi crypto

out id=0x31e3230, priority=70, domain=encrypt, deny=false

        hits=0, user_data=0x1d5958bc, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip=10.10.144.0, mask=255.255.254.0, port=0

        dst ip=10.114.25.0, mask=255.255.255.0, port=0

5) En estos momentos no se ven hitcounts para el tráfico interesante del túnel del VPN, por lo que procederíamos a revisar en el mismo comando, aquellos ids que incluyan el tráfico de origen ip=10.10.144.0, mask=255.255.254.0 y de destino ip=10.114.25.0, mask=255.255.255.0.

6) Podemos ver otro id para el mismo tráfico que si tiene hitcounts

out id=0x2c6f6f8, priority=70, domain=encrypt, deny=false

        hits=164384, user_data=0x84b491c, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip=10.10.144.0, mask=255.255.254.0, port=0

        dst ip=10.114.25.0, mask=255.255.255.0, port=0

El asp, puede no aparecer en ningún contexto y por lo tanto en ningún otro SPI de salida del túnel. Con esto podemos determinar que el ASA, está tratando de  usar otro SPI para cifrar el tráfico.

Este comportamiento puede  estar ocasionado por el bug, CSCtb53186  donde  el workaround es realizar un reload al ASA.

Gracias,

Itzcoatl Espinosa

1860
Visitas
0
ÚTIL
0
Comentarios