Verificando si un túnel IPSec sin tráfico se cae

Fecha: 21 al 26 de octubre del 2020

 

Escenario

 

Empecemos por afirmar que un un puente podría ser, pero es paradójico decir que un túnel se caiga.

Este laboratorio reproduce que pasaría si por algún motivo no hay tráfico que enviar por el túnel, y

despejar las dudas si el túnel se cae, y si es efectivo o no el keepalive.

 

 

 

Este escenario es bien simple, un router 1841 y un PIX conectados con un cable cruzado como WAN.

 

En otros laboratorios experimentamos con una VPN IPSec con pésimas condiciones de conectividad:

https://www.vilarrasa.com.ar/simulador_latencia.htm

 

Para comprender como se establece un tunel IPSec, podemos ver este lab:

https://www.vilarrasa.com.ar/diseccion_ipsec.htm

 

 

Recordemos que en Cisco, un túnel IPSec levanta recién cuando hay tráfico interesante para enviar.

 

1.- Verificación inicial:

 

Cisco1841#sh crypto isakmp policy

 

Global IKE policy

Protection suite of priority 10

        encryption algorithm:   AES - Advanced Encryption Standard (256 bit keys).

        hash algorithm:         Secure Hash Standard

        authentication method:  Pre-Shared Key

        Diffie-Hellman group:   #5 (1536 bit)

        lifetime:               180 seconds, no volume limit (cada 3 minutos renegocia la SA)

Default protection suite

        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).

        hash algorithm:         Secure Hash Standard

        authentication method:  Rivest-Shamir-Adleman Signature

        Diffie-Hellman group:   #1 (768 bit)

        lifetime:               86400 seconds, no volume limit (por default es 1 día)

Cisco1841#

 

2.- Configuramos el debugging ISAKMP:

 

Cisco1841#debug crypto isakmp

Crypto ISAKMP debugging is on

Cisco1841#

 

3.- Purgamos el túnel:

 

Para evitar cualquier prueba errónea nos aseguramos de tener el túnel abajo.

 

Cisco1841#clear crypto isakmp

Cisco1841#

 

4.- Generamos tráfico:

 

Cisco1841#ping 192.168.1.100 source 192.168.0.1

 

Type escape sequence to abort.

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

Packet sent with a source address of 192.168.0.1

...!!    (los 3 primeros pings se pierden en la negociación del túnel)

Cisco1841#

 

 

Los paquetes 1 a 9 son la negociación del túnel, los paquetes 10 y 11 son el echo-request (2 pings de 5 ya

que los 3 primeros se pierden), y los paquetes 12 y 13 son el echo-response (respuesta a los 2 pings) que

llegan por el túnel protegidos como ESP.

 

5.- Verificamos el UP del túnel:

 

5.1.- En fase 1:

 

Cisco1841#sh crypto isakm sa

dst             src                    state           conn-id   slot status

10.0.0.2        10.0.0.1        QM_IDLE              1    0  ACTIVE

Cisco1841#

 

5.2.- En fase 2:

 

Cisco1841#sh crypto ipsec sa

 

interface: FastEthernet0/1

    Crypto map tag: VPN, local addr 10.0.0.1

 

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)

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

   current_peer 10.0.0.2 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2 (los 3 primeros pings se pierden en la negociación del túnel)

    #pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 3, #recv errors 0

 

     local crypto endpt.: 10.0.0.1, remote crypto endpt.: 10.0.0.2

     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1

     current outbound spi: 0x8B1E198A(2334005642)

 

     inbound esp sas:

      spi: 0x5DE04E32(1574981170)

        transform: esp-256-aes esp-sha-hmac ,

     --- resumido ---

Cisco1841#

 

6.- Verificamos mediante el debug:

 

*Oct 22 18:41:51.482: ISAKMP: received ke message (1/1) (disparo de la VPN) (túnel UP)

--- resumido ---

*Oct 22 20:41:52.630: ISAKMP:(0:58:SW:1):purging SA., sa=62D8B024, delme=62D8B02  (DOWN del túnel a las 2 horas,

                                                                                                                                                     luego de renegociar 58 veces)

7.- Verificación de las renegociaciones:

 

Se puede ver que el número de connection-id aumenta cada aproximademente 2 minutos que es antes de expirar el lifetime,

y el túnel anterior se termina eliminando, llegando de 0 a 58 en 2 horas (59 x ~2 min = ~2 horas).

 

Cisco1841#sh crypto isakmp sa

dst             src             state                   conn-id slot status

10.0.0.1        10.0.0.2        QM_IDLE              2    0 ACTIVE (nuevo SA creado luego de 120 segundos)

10.0.0.1        10.0.0.2        QM_IDLE              1    0 ACTIVE

 

Cisco1841#

 

Cisco1841#sh crypto isakmp sa

dst             src             state          conn-id slot status

10.0.0.1        10.0.0.2        QM_IDLE               2    0 ACTIVE

10.0.0.1        10.0.0.2        MM_NO_STATE   1    0 ACTIVE (deleted) (se elimina el túnel original)

 

Cisco1841#

 

Cisco1841#sh crypto isakmp sa

dst             src             state          conn-id slot status

10.0.0.1        10.0.0.2        QM_IDLE              3    0 ACTIVE (nuevo SA creado luego de 120 segundos)

10.0.0.1        10.0.0.2        QM_IDLE              2    0 ACTIVE

 

Cisco1841#

 

Cisco1841#sh crypto isakmp sa

dst             src             state          conn-id slot status

10.0.0.1        10.0.0.2        QM_IDLE               3    0 ACTIVE

10.0.0.1        10.0.0.2        MM_NO_STATE   2    0 ACTIVE (deleted) (se elimina el túnel anterior)

 

Cisco1841#

 

--- luego de dos horas ---

 

Cisco1841#sh crypto isakmp sa

dst             src             state          conn-id slot status

10.0.0.1        10.0.0.2        QM_IDLE         58  0 ACTIVE

Cisco1841#

 

Cisco1841#sh crypto isakmp sa (ya no hay túnel)

dst             src             state          conn-id slot status

Cisco1841#

 

8.- Nueva prueba:

 

Se repite la prueba para verificar que la caída no haya sido por algo casual.

 

Cisco1841#ping 192.168.1.100 source 192.168.0.1

 

Type escape sequence to abort.

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

Packet sent with a source address of 192.168.0.1

..!!!  

Cisco1841#

 

*Oct 22 21:09:00.894: ISAKMP: received ke message (1/1) (túnel UP)

*Oct 22 21:09:00.894: ISAKMP:(0:0:N/A:0): SA request profile is (NULL)

*Oct 22 21:09:00.894: ISAKMP: Created a peer struct for 10.0.0.2, peer port 500

---omitido---

 

Cisco1841#sh crypto isakmp sa

dst             src                      state          conn-id slot status

10.0.0.2        10.0.0.1        QM_IDLE              1    0  ACTIVE

 

Cisco1841#

 

*Oct 22 23:09:02.489: ISAKMP:(0:58:SW:1):purging SA., sa=62D894D0, delme=62D894D0 (túnel DOWN nuevamente a las 2 horas)

 

Cisco1841#sh crypto isakmp sa

dst             src             state          conn-id slot status

 

Cisco1841#

 

9.- Analisis de logs del corte después de las dos horas:

 

Aquí podemos encontrar indicios que la caída no es solo por ISAKMP (fase 1) sino que las políticas de fase 2 (llamadas IPSec) intervienen.

 

9.1.- Del lado Router:

 

Cisco1841#sh crypto isakmp sa

dst             src                   state                    conn-id  slot status

10.0.0.1        10.0.0.2        MM_NO_STATE         58    0   ACTIVE (deleted)

 

Cisco1841#

 

*Oct 23 19:32:23.119: ISAKMP: Unlocking IPSEC struct 0x639541EC from delete_siblings, count 0

 

*Oct 23 19:34:08.739: ISAKMP (0:134217786): received packet from 10.0.0.2 dport 500 sport 500 Global (R) QM_IDLE

*Oct 23 19:34:08.743: ISAKMP: set new node -517186742 to QM_IDLE

*Oct 23 19:34:08.743: ISAKMP:(0:58:SW:1): processing HASH payload. message ID = -517186742

*Oct 23 19:34:08.743: ISAKMP:(0:58:SW:1): processing DELETE payload. message ID = -517186742

*Oct 23 19:34:08.743: ISAKMP:(0:58:SW:1):peer does not do paranoid keepalives.

 

*Oct 23 19:34:08.743: ISAKMP:(0:58:SW:1):deleting SA reason "No reason" state (R) QM_IDLE       (peer 10.0.0.2)

*Oct 23 19:34:08.743: ISAKMP:(0:58:SW:1):deleting node -517186742 error FALSE reason "Informational (in) state 1"

*Oct 23 19:34:08.743: ISAKMP: set new node 531216742 to QM_IDLE

*Oct 23 19:34:08.743: ISAKMP:(0:58:SW:1): sending packet to 10.0.0.2 my_port 500 peer_port 500 (R) QM_IDLE

*Oct 23 19:34:08.743: ISAKMP:(0:58:SW:1):purging node 531216742

*Oct 23 19:34:08.747: ISAKMP:(0:58:SW:1):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

*Oct 23 19:34:08.747: ISAKMP:(0:58:SW:1):Old State = IKE_P1_COMPLETE  New State = IKE_DEST_SA

 

*Oct 23 19:34:08.747: ISAKMP:(0:58:SW:1):deleting SA reason "No reason" state (R) QM_IDLE       (peer 10.0.0.2)

*Oct 23 19:34:08.747: ISAKMP: Unlocking IKE struct 0x639541EC for isadb_mark_sa_deleted(), count 0

*Oct 23 19:34:08.747: ISAKMP: Deleting peer node by peer_reap for 10.0.0.2: 639541EC

*Oct 23 19:34:08.747: ISAKMP:(0:58:SW:1):deleting node -517186742 error FALSE reason "IKE deleted"

*Oct 23 19:34:08.747: ISAKMP:(0:58:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

*Oct 23 19:34:08.747: ISAKMP:(0:58:SW:1):Old State = IKE_DEST_SA  New State = IKE_DEST_SA

 

9.2.- Del lado PIX:

 

Oct 23 2020 19:34:26: %PIX-7-702208: ISAKMP Phase 1 exchange started (local 10.0.0.2 (initiator), remote 10.0.0.1)

Oct 23 2020 19:34:26: %PIX-7-702212: ISAKMP Phase 1 initiating rekey (local 10.0.0.2 (initiator), remote 10.0.0.1)

Oct 23 2020 19:34:28: %PIX-7-702210: ISAKMP Phase 1 exchange completed (local 10.0.0.2 (initiator), remote 10.0.0.1)

Oct 23 2020 19:34:28: %PIX-6-602201: ISAKMP Phase 1 SA created (local 10.0.0.2/500 (initiator), remote 10.0.0.1/500,

authentication=pre-share, encryption=AES-CBC, hash=SHA, group=5, lifetime=180s)

Oct 23 2020 19:34:44: %PIX-7-702301: lifetime expiring, (sa) sa_dest= 10.0.0.1, sa_prot= 50, sa_spi= 0x57143489(1460941961),

 sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 4, (identity) local= 10.0.0.2, remote= 10.0.0.1,

local_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4), remote_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4)

Oct 23 2020 19:34:44: %PIX-6-602302: deleting SA, (sa) sa_dest= 10.0.0.2, sa_prot= 50, sa_spi= 0xef94f058(4019515480),

 sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 3

Oct 23 2020 19:34:44: %PIX-6-602302: deleting SA, (sa) sa_dest= 10.0.0.1, sa_prot= 50, sa_spi= 0x57143489(1460941961),

 sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 4

Oct 23 2020 19:34:23: %PIX-7-702201: ISAKMP Phase 1 delete received (local 10.0.0.2 (initiator), remote 10.0.0.1)

Oct 23 2020 19:34:28: %PIX-6-602203: ISAKMP session disconnected (local 10.0.0.2 (initiator), remote 10.0.0.1)

Oct 23 2020 19:34:29: %PIX-7-702202: ISAKMP Phase 1 delete sent (local 10.0.0.2 (initiator), remote 10.0.0.1)

 

10.- Prueba con mayor lifetime en fase 2:

 

En este caso probamos con un lifetime de 7200 segundos, el doble del tiempo de las primeras pruebas, con esto el túnel

“debería” caerse aproximadamente a las 4 horas de iniciado el túnel y luego sin tráfico.

 

Cisco1841(config-crypto-map)# set security-association lifetime seconds 7200

Cisco1841(config-crypto-map)#

 

PIX501(config)# crypto map vpn_map 10 set security-association lifetime seconds 7200

PIX501(config)#

 

11.- Generamos tráfico:

 

Cisco1841#ping 192.168.1.100 source 192.168.0.1

 

Type escape sequence to abort.

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

Packet sent with a source address of 192.168.0.1

 

12.- Verificación:

 

12.1.- En el router:

 

Podemos ver que expira el SA número 116, esto es 117 * 2 = 234 minutos / 60 = 3,9 horas = ~4 horas

Contamos 117 porque la cuenta arranca desde la SA 0:0.

 

*Oct 24 10:27:33.079: ISAKMP: received ke message (1/1) (levanta el túnel)

 

*Oct 24 14:26:21.474: ISAKMP:(0:116:SW:1):deleting SA reason "No reason" state (R) QM_IDLE       (peer 10.0.0.2)

*Oct 24 14:26:21.474: ISAKMP: Unlocking IKE struct 0x639B0494 for isadb_mark_sa_deleted(), count 0

*Oct 24 14:26:21.474: ISAKMP: Deleting peer node by peer_reap for 10.0.0.2: 639B0494

*Oct 24 14:26:21.474: ISAKMP:(0:116:SW:1):deleting node 1413883260 error FALSE reason "IKE deleted"

*Oct 24 14:26:21.474: ISAKMP:(0:116:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

*Oct 24 14:26:21.474: ISAKMP:(0:116:SW:1):Old State = IKE_DEST_SA  New State = IKE_DEST_SA

 

*Oct 24 14:27:11.474: ISAKMP:(0:116:SW:1):purging node 1413883260

*Oct 24 14:27:21.474: ISAKMP:(0:116:SW:1):purging SA., sa=62D89BBC, delme=62D89BBC

 

12.2.- En el PIX:

 

Oct 24 2020 10:29:16: %PIX-7-702208: ISAKMP Phase 1 exchange started (local 10.0.0.2 (responder), remote 10.0.0.1) (levanta el túnel)

 

12.2.1.- Primer tiempo de expiración de clave (2 horas):

 

Oct 24 2020 12:25:50: %PIX-7-702301: lifetime expiring, (sa) sa_dest= 10.0.0.1, sa_prot= 50, sa_spi= 0xb0e13ce6(2967551206),

sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 1, (identity) local= 10.0.0.2, remote= 10.0.0.1,

local_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4), remote_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4)

 

 

Aquí podemos ver la renegociación de una nueva SA antes de los 3600 segundos, y que luego expirará por

no tener tráfico y pondrá la SA (el túnel) en DOWN.

 

12.2.2.- Segundo tiempo de expiración de clave (2 horas, 4 en total):

 

Oct 24 2020 14:25:05: %PIX-7-702301: lifetime expiring, (sa) sa_dest= 10.0.0.1, sa_prot= 50, sa_spi= 0x701de2ed(1881006829),

sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 4, (identity) local= 10.0.0.2, remote= 10.0.0.1,

local_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4), remote_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4)

 

Oct 24 2020 14:25:05: %PIX-6-602302: deleting SA, (sa) sa_dest= 10.0.0.2, sa_prot= 50, sa_spi= 0xd798392e(3617077550),

sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 3

Oct 24 2020 14:25:05: %PIX-6-602302: deleting SA, (sa) sa_dest= 10.0.0.1, sa_prot= 50, sa_spi= 0x701de2ed(1881006829),

sa_trans= esp-aes-256 esp-sha-hmac , sa_conn_id= 4

Oct 24 2020 14:25:50: %PIX-7-702201: ISAKMP Phase 1 delete received (local 10.0.0.2 (initiator), remote 10.0.0.1)

Oct 24 2020 14:26:55: %PIX-6-602203: ISAKMP session disconnected (local 10.0.0.2 (initiator), remote 10.0.0.1)

Oct 24 2020 14:26:56: %PIX-7-702202: ISAKMP Phase 1 delete sent (local 10.0.0.2 (initiator), remote 10.0.0.1)

 

 

Aquí podemos ver la finalización de la SA por cumpirse la lifetime sin tráfico.

 

13.- Generando tráfico casi al final del primer lifetime:

 

Con esta prueba generamos tráfico 5 minutos antes de que expire el primer lifetime de la fase 2, para

comprobar si el túnel se teniendo sólo un lifetime completo sin tráfico.

En el primer ciclo esto no es posible ya que se necesita tráfico para levantar el túnel, pero en el segundo

esto si es posible.

 

13.1.- Verificamos tiempo restante al lifetime de fase 2:

 

Rosario#sh crypto ipsec sa

 

interface: FastEthernet0/1

    Crypto map tag: VPN, local addr 10.0.0.1

 

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)

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

   current_peer 10.0.0.2 port 500

     PERMIT, flags={origin_is_acl,}

    #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: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 6, #recv errors 0

 

     local crypto endpt.: 10.0.0.1, remote crypto endpt.: 10.0.0.2

     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1

     current outbound spi: 0x64887860(1686665312)

 

     inbound esp sas:

      spi: 0x82C83548(2194158920)

        transform: esp-256-aes esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 3004, flow_id: FPGA:4, crypto map: VPN

        sa timing: remaining key lifetime (k/sec): (4588259/368)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE

 

Rosario#

 

13.2.- Generamos tráfico:

 

Rosario#ping 192.168.1.100 source fa0/0

 

Type escape sequence to abort.

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

Packet sent with a source address of 192.168.0.1

!!!!!

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

Rosario#

 

13.3.- Verificamos que el tunel cae luego de sólo el segundo lifetime sin actividad:

 

*Oct 26 19:20:44.222: ISAKMP:(0:57:SW:1):purging node -273504197

*Oct 26 19:20:44.222: ISAKMP:(0:57:SW:1):purging node 919626995

*Oct 26 19:20:54.222: ISAKMP:(0:57:SW:1):purging SA., sa=63A83EB0, delme=63A83EB0

 

Rosario#sh crypto isakmp sa

dst             src             state          conn-id slot status

 

Rosario#

 

14.- Datos relevantes de la página de Cisco:

 

How DPD and Cisco IOS Keepalive Features Work:

 

DPD and Cisco IOS keepalives function on the basis of the timer: If the timer is set for 10 seconds, the router sends a "hello"

message every 10 seconds (unless, of course, the router receives a "hello" message from the peer).

The benefit of IOS keepalives and periodic DPD is earlier detection of dead peers. However, IOS keepalives and periodic DPD

rely on periodic messages that have to be sent with considerable frequency. The result of sending frequent messages is that the

communicating peers must encrypt and decrypt more packets.

 

DPD also has an on-demand approach. The contrasting on-demand approach is the default. With on-demand DPD, messages

are sent on the basis of traffic patterns. For example, if a router has to send outbound traffic and the liveliness of the peer is

questionable, the router sends a DPD message to query the status of the peer. If a router has no traffic to send, it never sends

a DPD message. If a peer is dead, and the router never has any traffic to send to the peer, the router does not discover this until

the IKE or IPsec security association (SA) has to be rekeyed (the liveliness of the peer is unimportant if the router is not trying to

communicate with the peer). On the other hand, if the router has traffic to send to the peer, and the peer does not respond, the

router initiates a DPD message to determine the state of the peer.

 

Fuente: https://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dplane/configuration/15-1mt/sec-ipsec-dead-peer.html

 

Como podemos observar, DPD no mantiene el túnel activo sino que solo detecta su caída.

 

15.- Resúmen:

 

Al menos con equipos Cisco, el túnel IPSec si se cae por inactividad.

 

Por las pruebas realizadas, se asume que durante el primer lifetime existe tráfico (2 pings ida y vuelta que levantan el túnel),

cumpliendose a los 3600 segundos y renovandose. Al renovarse, el segundo lifetime se cumple sin tráfico cerrando el túnel.

 

Se pueden configurar valores altos de lifetime para “alargar” este efecto, el máximo (y por default) es 86400 segundos (1 día),

esto puede no es recomendable porque cuanto mayor tiempo de vida tenga una clave, mas chances tiene de comprometerse.

 

Lo recomendable es mantener algún tipo de tráfico cada cierto período que mantenga el túnel UP.

 

Queda a la imaginación del administrador.

 

16.- Configuración de los equipos:

 

PIX501# sh runn (solo lo mas relevante)

: Saved

:

PIX Version 6.3(5)

---omitido---

nameif ethernet0 outside security0

nameif ethernet1 inside security100

---omitido---

hostname PIX501

---omitido---

access-list 100 permit ip 192.168.1.0 255.255.255.0 192.168.0.0 255.255.255.0

---omitido---

ip address outside 10.0.0.2 255.255.255.255

ip address inside 192.168.1.1 255.255.255.0

---omitido---

route outside 0.0.0.0 0.0.0.0 10.0.0.1 1

---omitido---

sysopt connection permit-ipsec

crypto ipsec transform-set ENCRIPTA esp-aes-256 esp-sha-hmac (fase 2 IPSec)

crypto map vpn_map 10 ipsec-isakmp

crypto map vpn_map 10 match address 100

crypto map vpn_map 10 set peer 10.0.0.1

crypto map vpn_map 10 set transform-set ENCRIPTA

crypto map vpn_map 10 set security-association lifetime seconds 7200

crypto map vpn_map interface outside

isakmp enable outside

isakmp key ******** address 10.0.0.1 netmask 255.255.255.255 (fase 1 IPSec)

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption aes-256

isakmp policy 10 hash sha

isakmp policy 10 group 5

isakmp policy 10 lifetime 180

---omitido---

Cryptochecksum:86db04ba3062a3823d5c545e40099cc3

: end

PIX501#

 

Cisco1841# sh runn (solo lo mas relevante)

Building configuration...

 

Current configuration : 1556 bytes

!

! Last configuration change at 20:05:06 UTC Fri Oct 23 2020

! NVRAM config last updated at 20:05:08 UTC Fri Oct 23 2020

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime localtime

!

hostname Cisco1841

!

logging buffered 4096 debugging

!

crypto isakmp policy 10 (fase 1 IPSec)

 encr aes 256

 authentication pre-share

 group 5

 lifetime 180

crypto isakmp key Pr3sh4redKey address 10.0.0.2

!

crypto ipsec transform-set TRANSFORMA esp-aes 256 esp-sha-hmac (fase 2 IPSec)

!

crypto map VPN 10 ipsec-isakmp (fase 2 IPSec)

 set peer 10.0.0.2

 set security-association lifetime seconds 7200

 set transform-set TRANSFORMA

 set pfs group5

 match address 101

!

interface FastEthernet0/0

 ip address 192.168.0.1 255.255.255.0

!

interface FastEthernet0/1

 ip address 10.0.0.1 255.255.255.0

crypto map VPN

!

ip route 192.168.1.0 255.255.255.0 10.0.0.2

!

logging trap debugging

logging 192.168.0.100

!

access-list 101 permit ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255 (fase 2 IPSec)

!

end

 

Cisco1841#

 

 

(2020) The light at the end of the tunnel

Rosario, Argentina