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