El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo configurar una conexión VPN IKEv2 de sitio a sitio entre Cisco FTD y StrongSwan mediante la autenticación de certificación.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
En esta configuración, HOST-A en LAN-A quiere comunicarse con HOST-B en LAN-B. Este tráfico debe cifrarse y enviarse a través de un túnel IKEv2 entre FTD y el servidor Ubuntu que ejecuta StrongSwan. Ambos peers se autentican mutuamente con la Autenticación de certificados.
1. En el CSP, vaya a Objects > Object Management > PKI > Cert Enrollment
.
2. Haga clic Add Cert Enrollment
.
3. La sección Nombre es un campo obligatorio; asigne un nombre al punto de confianza.
4. Se utiliza la inscripción de certificados manual. En la ficha de información de la CA, pegue el certificado del emisor.
Nota: si no tiene un certificado de emisor, puede seguir generando CSR sin él y, después de firmar su CSR desde la CA, editar el punto de confianza como se menciona en el paso 1 y pegar la información de la CA como se describe en el paso 4.
5. En el campo Parámetros de Certificado, introduzca los parámetros según las necesidades.
6. En el campo Clave, puede utilizar el par de claves RSA por defecto o generar uno nuevo editando el campo Nombre de Clave.
Nota: si utiliza una autoridad de certificación (CA) de Windows, la extensión predeterminada de las directivas de aplicación es IP security IKE intermediate. Si utiliza esta configuración predeterminada, debe elegir la opción Omitir uso de clave IPsec en la sección Configuración avanzada de la ficha Clave del cuadro de diálogo Inscripción de certificados PKI para el objeto que elija. De lo contrario, los terminales no pueden completar la conexión VPN de sitio a sitio.
7. En el campo Revocación, seleccione la casilla de control situada junto a Consider the Certificate valid if revocation information can not be reached
. No se utilizan comprobaciones de CRL ni OCSP. Click Save.
Nota: Si el dispositivo puede alcanzar los servidores CRL u OCSP desde el FTD, puede habilitar la comprobación de revocación extensa para obtener el estado del certificado. La casilla Considerar el certificado válido si no se puede alcanzar la información de revocación está habilitada sólo cuando no hay conectividad entre el servidor CRL y el dispositivo FTD. Esta opción está activada de forma predeterminada en el CSP.
8. A continuación, navegue hasta Devices > Certificates
, haga clic en Add
y elija el dispositivo FTD y el punto de confianza que ha creado. A continuación, haga clic en Add
.
9. Puede comprobar el certificado del emisor haciendo clic en el icono de lupa marcado como CA
.
10. Se obtiene un resultado similar.
11. En el paso siguiente, debe hacer clic en el botón ID
y se obtiene una ventana emergente para generar una CSR. Haga clic en Yes
.
12. Una vez que haya devuelto el archivo de certificado de identidad de la CA, puede importarlo mediante el Browse Identity Certificate
y haciendo clic en Import
.
Nota: Si recibe un error relativo a Import failed due to weak crypto characteristics
,use el comando Enable weak-crypto
como se muestra y una vez que reciba la ventana emergente, haga clic en Sí para continuar.
13. Repita los pasos para generar el CSR e importe el certificado de identidad.
No es necesario volver a enviar la CSR, ya que no se ha modificado nada del dispositivo. Puede importar directamente el certificado emitido accediendo a la CA.
14. Ahora puede ver el certificado de identidad haciendo clic en el icono de lupa marcado como ID
.
15. El certificado se ha agregado correctamente.
1. Acceda a Devices > Site to Site VPN
.
2. Haga clic Add > VPN Tunnel
.
3. Introduzca el nombre de topología, que es un campo obligatorio. Policy based (Crypto Map)
, Point-to-Point Topology
,y IKEv2
están seleccionadas de forma predeterminada y debe utilizarlas.
4. En la sección Terminales, haga clic en el botón +
situado junto al nodo A.
5. Elija el dispositivo FTD como Nodo A y la interfaz de terminación de VPN será la interfaz externa.
6. En el campo Redes protegidas, seleccione la Subred/Dirección IP (Red) y haga clic en el botón +
icono.
7. Haga clic en el icono + situado junto a Available Networks
.
8. Aquí se define la red, el host o el intervalo de direcciones IP detrás del FTD que deben protegerse. En este caso, es hostA el que tiene la dirección IP 10.106.70.110/32. Haga clic en Save
.
9. Contabilizar que elija el nombre introducido para el objeto de red en el paso anterior y haga clic en Add
. Ahora puede ver el nombre del objeto de red configurado en Redes seleccionadas. Haga clic en OK
.
10. Ahora puede ver el objeto de red configurado en la lista Redes protegidas. Haga clic en OK
. El punto final de FTD ahora está configurado y la siguiente configuración de peer-side remoto.
11. Realice el mismo proceso para el nodo B. Haga clic en el botón +
situado junto al nodo B.
12. Si el dispositivo par remoto es externo, debe elegir el dispositivo como Extranet. Agregue el nombre del dispositivo y su dirección IP de acceso público como la dirección de peer.
13. En el campo Redes protegidas, seleccione Subred/Dirección IP (Red) y haga clic en +
.
14. Haga clic en el botón +
situado junto a Redes disponibles.
15. Introduzca el host, la red o el intervalo de direcciones IP que desea proteger y que se encuentran detrás del servidor Ubuntu. En este caso, es hostB el que tiene la dirección IP 10.106.71.110/32. Click Save.
16. Contabilizar que seleccione el nombre introducido para el objeto de red en el paso anterior y haga clic en Add
, Ahora puede ver el Nombre del objeto de red configurado en Redes seleccionadas. Haga clic en OK
.
17. Ahora, puede ver el objeto de red configurado en la lista de redes protegidas. Click OK.
18. Ahora se configuran los terminales y las redes que deben protegerse.
19. A continuación, desde la sección Terminales, pasa a la sección IKE. Edite las directivas de la configuración de IKEv2 haciendo clic en el botón Pencil
junto a Directivas.
20. En la sección de políticas, Encryption AES
, Integrity SHA1
, PRF SHA1
, DH Group 14 (mod 2048)
,y FTD-StrongSwan-IKEv2-Phase1
se utilizan.
21. Deje el mapa criptográfico predeterminado como estático y el modo IKEv2 como Túnel. En Conjuntos de transformación, haga clic en el botón Pencil
junto a las propuestas. En las propuestas, elija Encryption AES
,
Integrity sha-1
,y PFS DH group 14 (2048)
como las propuestas del FTD-StrongSwan-IPSec.
22. Ahora, desde el panel de navegación de la parte superior, navegue hasta Policies > Access Control
. Edite el ACP para el FTD con el que está tratando.
23. Pulse Add Rule
.
24. La regla predeterminada es bloquear todo el tráfico para permitir el flujo de tráfico bidireccional entre hostA y hostB. Si ha configurado zonas, elija las relevantes y agréguelas para el origen y el destino. Haga clic en Add
.
25. Después de agregar la regla, haga clic en Save
.
26. Finalmente, debe configurar una sentencia No NAT para que el tráfico VPN quede exento en caso de que haya alguna NAT presente en el FTD. Desplácese hasta Devices > NAT
. Haga clic en Add Rule
.
27. Agregue los objetos de interfaz relevantes y, en la sección de traducción, elija el origen Original y Traducido como la red protegida por VPN detrás del FTD, que es hostA en este caso. De manera similar, para los destinos Original y Translated, elija la red protegida por VPN detrás del extremo remoto, que es hostB en este caso.
28. En la sección Avanzado, asegúrese de comprobar el Do not proxy ARP on Destination Interface
y Perform Route Lookup for Destination Interface
casillas de verificación, que son necesarias para las sentencias No NAT.
Todos los comandos mostrados necesitan permisos sudo. Póngase en contacto con el administrador del sistema si no dispone de acceso sudo ni de permisos para instalar el software. Las configuraciones oficiales de StrongSwan se pueden encontrar aquí.
1. Comience actualizando la memoria caché del paquete del sistema.
apt update
2. Instale StrongSwan y sus dependencias. Puede encontrar más información sobre los paquetes aquí.
apt install strongswan strongswan-pki strongswan-swanctl libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins
3. Compruebe el estado del demonio StrongSwan. El estado debe mostrar activo (en ejecución).
systemctl status strongswan-starter.service
4. Si por alguna razón no lo es, habilitarlo e iniciarlo con este comando.
systemctl enable --now strongswan-starter.service
5. A continuación, utilice el strong-swan pki
para generar la clave privada y CSR. Para generar una clave privada para el servidor ejecute este comando.
pki --gen > sswan.priv.key
6. Generar solicitudes CSR para el servidor StrongSwan. Puede modificar el --dn
según sus requisitos.
pki --req --in sswan.priv.key --dn "CN=sswan.test.local, O=Cisco, OU=TAC, ST=KA, C=IN" --outform pem > sswan.test.local.pem
7. Después de obtener la CSR firmada por la CA, copie el certificado del emisor, el certificado de identidad y la clave privada en la /etc/swanctl
directorio.
cp $HOME/certs/root-ca.cer /etc/swanctl/x509ca/
cp $HOME/certs/sswan.test.local.cer /etc/swanctl/x509/
cp $HOME/certs/sswan.priv.key /etc/swanctl/private/
connections {
strongswan-ftd {
# Peer IP's
local_addrs = 10.106.67.200
remote_addrs = 10.106.69.230
local {
auth = pubkey
certs = sswan.test.local.cer
id = "sswan.test.local"
}
remote {
auth = pubkey
id = "C=IN, ST=KA, L=Bangalore, O=Cisco, OU=TAC, CN=ftd72.test.local"
}
children {
hostB-hostA {
local_ts = 10.106.71.110/32
remote_ts = 10.106.70.110/32
rekey_time = 28800 # Phase-2 Lifetime
esp_proposals = aes-sha-modp2048 # Phase-2 Paramters
}
}
mobike = no
version = 2 # IKE version 2
reauth_time = 86400 # Phase-1 Lifetime
proposals = aes-sha-prfsha1-modp2048 # Phase-1 Paramters
}
}
1. Compruebe los parámetros de fase 1 de IKEv2.
firepower# sh run crypto ikev2
crypto ikev2 policy 1
encryption aes
integrity sha
group 14
prf sha
lifetime seconds 86400
crypto ikev2 enable outside
2. Compruebe los parámetros de la fase 2.
firepower# sh run crypto ipsec
crypto ipsec ikev2 ipsec-proposal CSM_IP_2
protocol esp encryption aes
protocol esp integrity sha-1
3. Compruebe la configuración del mapa criptográfico.
Nota: En la versión FTD 7.2.0, el valor predeterminado PFS is DH Group 14 (MOD 2048)
. Puede verificar el mismo si running sh run all crypto map
.
firepower# sh run crypto map
crypto map CSM_outside_map 1 match address CSM_IPSEC_ACL_1
crypto map CSM_outside_map 1 set pfs
crypto map CSM_outside_map 1 set peer 10.106.67.200
crypto map CSM_outside_map 1 set ikev2 ipsec-proposal CSM_IP_2
crypto map CSM_outside_map 1 set trustpoint IPSEC-StrongSwan
crypto map CSM_outside_map 1 set reverse-route
crypto map CSM_outside_map interface outside
4. Verifique la ACL criptográfica.
firepower# sh access-list CSM_IPSEC_ACL_1
access-list CSM_IPSEC_ACL_1; 1 elements; name hash: 0x1fb1fb7
access-list CSM_IPSEC_ACL_1 line 1 extended permit ip host 10.106.70.110 host 10.106.71.110 (hitcnt=37) 0xc8d25938
5. Compruebe el estado del túnel.
firepower# sh vpn-sessiondb det l2l
Session Type: LAN-to-LAN Detailed
Connection : 10.106.67.200
Index : 61 IP Addr : 10.106.67.200
Protocol : IKEv2 IPsec
Encryption : IKEv2: (1)AES128 IPsec: (1)AES128
Hashing : IKEv2: (1)SHA1 IPsec: (1)SHA1
Bytes Tx : 0
Bytes Rx : 0
Login Time : 12:16:25 UTC Mon Jul 17 2023
Duration : 0h:11m:30s
Tunnel Zone : 0
IKEv2 Tunnels: 1
IPsec Tunnels: 1
IKEv2:
Tunnel ID : 61.1
UDP Src Port : 500 UDP Dst Port : 500
Rem Auth Mode: rsaCertificate
Loc Auth Mode: rsaCertificate
Encryption : AES128 Hashing : SHA1
Rekey Int (T): 86400 Seconds Rekey Left(T): 85710 Seconds
PRF : SHA1 D/H Group : 14
Filter Name :
IPsec:
Tunnel ID : 61.2
Local Addr : 10.106.70.110/255.255.255.255/0/0
Remote Addr : 10.106.71.110/255.255.255.255/0/0
Encryption : AES128 Hashing : SHA1
Encapsulation: Tunnel PFS Group : 14
Rekey Int (T): 28800 Seconds Rekey Left(T): 28110 Seconds
Rekey Int (D): 4608000 K-Bytes Rekey Left(D): 4608000 K-Bytes
Idle Time Out: 30 Minutes Idle TO Left : 29 Minutes
Conn Time Out: 1032728 Minutes Conn TO Left : 1032714 Minutes
Bytes Tx : 600 Bytes Rx : 880
Pkts Tx : 10 Pkts Rx : 10
6. Compruebe los contadores de SA IPSEC.
firepower# sh cry ipsec sa
interface: outside
Crypto map tag: CSM_outside_map, seq num: 1, local addr: 10.106.69.230
access-list CSM_IPSEC_ACL_1 extended permit ip host 10.106.70.110 host 10.106.71.110
Protected vrf:
local ident (addr/mask/prot/port): (10.106.70.110/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (10.106.71.110/255.255.255.255/0/0)
current_peer: 10.106.67.200
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
1. Compruebe las conexiones cargadas. Si no se ve ninguna conexión, ejecute el swanctl --load-all
.
root@strongswan:~# swanctl --list-conn
strongswan-ftd: IKEv2, reauthentication every 86400s, no rekeying
local: 10.106.67.200
remote: 10.106.69.230
local public key authentication:
id: sswan.test.local
certs: C=IN, ST=KA, O=Cisco, OU=TAC, CN=sswan.test.local
remote public key authentication:
id: C=IN, ST=KA, L=Bangalore, O=Cisco, OU=TAC, CN=ftd72.test.local
hostB-hostA: TUNNEL, rekeying every 28800s
local: 10.106.71.110/32
remote: 10.106.70.110/32
2. Compruebe el estado SA del hijo.
root@strongswan:~# swanctl --list-sas
strongswan-ftd: #11, ESTABLISHED, IKEv2, 791c5a5633f9ea83_i a4e0487769c49dad_r*
local 'sswan.test.local' @ 10.106.67.200[500]
remote 'C=IN, ST=KA, L=Bangalore, O=Cisco, OU=TAC, CN=ftd72.test.local' @ 10.106.69.230[500]
AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
established 279s ago, reauth in 83226s
hostB-hostA: #8, reqid 6, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96
installed 279s ago, rekeying in 25753s, expires in 31401s
in cc01a2a7, 600 bytes, 10 packets, 10s ago
out 3594c049, 600 bytes, 10 packets, 10s ago
local 10.106.71.110/32
remote 10.106.70.110/32
debug crypto condition peer 10.106.67.200
debug crypto ikev2 platfform 127
debug crypto ikev2 protocol 127
debug crypto ipsec 127
La validación de ID de par está activada.
==== OUTPUT OMITTED ====
IKEv2-PLAT-4: (203): Peer ID check started, received ID type: IPv4 address
IKEv2-PLAT-4: (203): Peer ID check: failed to retreive IP from SAN
IKEv2-PLAT-4: (203): Peer ID check: failed to retreive DNS name from SAN
IKEv2-PLAT-4: (203): Peer ID check: failed to retreive RFC822 name from SAN
IKEv2-PLAT-4: (203): retrieving SAN for peer ID check
IKEv2-PLAT-2: (203): Peer ID check failed
IKEv2-PROTO-2: (203): Failed to locate an item in the database
IKEv2-PROTO-7: (203): SM Trace-> SA: I_SPI=40DC7DC3A0BDF20D R_SPI=E02399BAC06E0944 (I) MsgID = 00000001 CurState: I_PROC_AUTH Event: EV_AUTH_FAIL
IKEv2-PROTO-4: (203): Verification of peer's authentication data FAILED
IKEv2-PROTO-7: (203): SM Trace-> SA: I_SPI=40DC7DC3A0BDF20D R_SPI=E02399BAC06E0944 (I) MsgID = 00000001 CurState: AUTH_DONE Event: EV_FAIL
IKEv2-PROTO-4: (203): Auth exchange failed
IKEv2-PROTO-2: (203): Auth exchange failed
IKEv2-PROTO-2: (203): Auth exchange failed
IKEv2-PROTO-7: (203): SM Trace-> SA: I_SPI=40DC7DC3A0BDF20D R_SPI=E02399BAC06E0944 (I) MsgID = 00000001 CurState: EXIT Event: EV_ABORT
IKEv2-PROTO-7: (203): SM Trace-> SA: I_SPI=40DC7DC3A0BDF20D R_SPI=E02399BAC06E0944 (I) MsgID = 00000001 CurState: EXIT Event: EV_CHK_PENDING_ABORT
IKEv2-PLAT-7: Negotiating SA request deleted
IKEv2-PLAT-7: Decrement count for outgoing negotiating
IKEv2-PROTO-7: (203): SM Trace-> SA: I_SPI=40DC7DC3A0BDF20D R_SPI=E02399BAC06E0944 (I) MsgID = 00000001 CurState: EXIT Event: EV_UPDATE_CAC_STATS
IKEv2-PROTO-4: (203): Abort exchange
IKEv2-PROTO-4: (203): Deleting SA
==== OUTPUT OMITTED ====
root@strongswan:~# swanctl --log
01[NET] received packet: from 10.106.69.230[500] to 10.106.67.200[500] (574 bytes)
01[ENC] parsed IKE_SA_INIT request 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) V ]
01[IKE] received Cisco Delete Reason vendor ID
01[IKE] received Cisco Copyright (c) 2009 vendor ID
01[IKE] received FRAGMENTATION vendor ID
01[IKE] 10.106.69.230 is initiating an IKE_SA
01[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
01[IKE] sending cert request for "DC=local, DC=test, CN=test-WS2012-CA"
01[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
01[NET] sending packet: from 10.106.67.200[500] to 10.106.69.230[500] (481 bytes)
06[NET] received packet: from 10.106.69.230[500] to 10.106.67.200[500] (528 bytes)
06[ENC] parsed IKE_AUTH request 1 [ EF(1/5) ]
06[ENC] received fragment #1 of 5, waiting for complete IKE message
07[NET] received packet: from 10.106.69.230[500] to 10.106.67.200[500] (528 bytes)
07[ENC] parsed IKE_AUTH request 1 [ EF(2/5) ]
07[ENC] received fragment #2 of 5, waiting for complete IKE message
12[NET] received packet: from 10.106.69.230[500] to 10.106.67.200[500] (528 bytes)
12[ENC] parsed IKE_AUTH request 1 [ EF(3/5) ]
12[ENC] received fragment #3 of 5, waiting for complete IKE message
11[NET] received packet: from 10.106.69.230[500] to 10.106.67.200[500] (528 bytes)
11[ENC] parsed IKE_AUTH request 1 [ EF(4/5) ]
11[ENC] received fragment #4 of 5, waiting for complete IKE message
09[NET] received packet: from 10.106.69.230[500] to 10.106.67.200[500] (208 bytes)
09[ENC] parsed IKE_AUTH request 1 [ EF(5/5) ]
09[ENC] received fragment #5 of 5, reassembled fragmented IKE message (2012 bytes)
09[ENC] parsed IKE_AUTH request 1 [ V IDi CERT CERTREQ AUTH SA TSi TSr N(INIT_CONTACT) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
09[IKE] received cert request for "DC=local, DC=test, CN=test-WS2012-CA"
09[IKE] received end entity cert "C=IN, ST=KA, L=Bangalore, O=Cisco, OU=TAC, CN=ftd72.test.local"
09[CFG] looking for peer configs matching 10.106.67.200[%any]...10.106.69.230[C=IN, ST=KA, L=Bangalore, O=Cisco, OU=TAC, CN=ftd72.test.local]
09[CFG] selected peer config 'strongswan-ftd'
09[CFG] using certificate "C=IN, ST=KA, L=Bangalore, O=Cisco, OU=TAC, CN=ftd72.test.local"
09[CFG] using trusted ca certificate "DC=local, DC=test, CN=test-WS2012-CA"
09[CFG] reached self-signed root ca with a path length of 0
09[CFG] checking certificate status of "C=IN, ST=KA, L=Bangalore, O=Cisco, OU=TAC, CN=ftd72.test.local"
09[CFG] fetching crl from 'ldap:///CN=test-WS2012-CA,CN=ws2012,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=test,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint' ...
09[LIB] LDAP bind to 'ldap:///CN=test-WS2012-CA,CN=ws2012,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=test,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint' failed: Can't contact LDAP server
09[CFG] crl fetching failed
09[CFG] certificate status is not available
09[IKE] authentication of 'C=IN, ST=KA, L=Bangalore, O=Cisco, OU=TAC, CN=ftd72.test.local' with RSA signature successful
09[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
09[IKE] authentication of 'sswan.test.local' (myself) with RSA signature successful
09[IKE] IKE_SA strongswan-ftd[11] established between 10.106.67.200[sswan.test.local]...10.106.69.230[C=IN, ST=KA, L=Bangalore, O=Cisco, OU=TAC, CN=ftd72.test.local]
09[IKE] scheduling reauthentication in 83505s
09[IKE] maximum IKE_SA lifetime 92145s
09[IKE] sending end entity cert "C=IN, ST=KA, O=Cisco, OU=TAC, CN=sswan.test.local"
09[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
09[IKE] CHILD_SA hostB-hostA{8} established with SPIs cc01a2a7_i 3594c049_o and TS 10.106.71.110/32 === 10.106.70.110/32
09[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH SA TSi TSr N(AUTH_LFT) ]
09[ENC] splitting IKE message (1852 bytes) into 2 fragments
09[ENC] generating IKE_AUTH response 1 [ EF(1/2) ]
09[ENC] generating IKE_AUTH response 1 [ EF(2/2) ]
09[NET] sending packet: from 10.106.67.200[500] to 10.106.69.230[500] (1248 bytes)
09[NET] sending packet: from 10.106.67.200[500] to 10.106.69.230[500] (672 bytes)
12[NET] received packet: from 10.106.69.230[500] to 10.106.67.200[500] (76 bytes)
12[ENC] parsed INFORMATIONAL request 2 [ ]
12[ENC] generating INFORMATIONAL response 2 [ ]
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
28-Jul-2023 |
Versión inicial |