Configurer un tunnel site à site entre FTD et le serveur StrongSwan
Table des matières
Introduction
Ce document décrit comment configurer une connexion VPN de site à site IKEv2 entre Cisco FTD et StrongSwan à l'aide de l'authentification de certification.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- VPN de site à site
- Authentification par certificat (IKEv2)
- Infrastructures à clé publique (PKI)
- Connaissances de base de StrongSwan
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- Cisco FTD exécutant la version 7.2.0 build 18
- Cisco FMC version 7.2.0 build 18
- Serveur Ubuntu Exécutant La Version 20.04 (Focal Fossa)
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Configurer
Scénario
Dans cette configuration, HOST-A dans LAN-A veut communiquer avec HOST-B dans LAN-B. Ce trafic doit être chiffré et envoyé via un tunnel IKEv2 entre FTD et le serveur Ubuntu exécutant StrongSwan. Les deux homologues s'authentifient mutuellement avec l'authentification par certificat.
Diagramme du réseau
Configuration FMC
Obtention d'un certificat pour FTD
1. À partir du FMC, accédez à Objects > Object Management > PKI > Cert Enrollment.
2. Cliquez sur Add Cert Enrollment.
3. La section Nom est un champ obligatoire ; donnez un nom au point de confiance.
4. L'inscription manuelle de certificat est utilisée. Dans l'onglet Informations sur l'autorité de certification, collez le certificat émetteur.
Remarque : si vous ne disposez pas d'un certificat d'émetteur, vous pouvez continuer à générer un CSR sans celui-ci, et après avoir obtenu votre CSR signé de l'autorité de certification, modifiez le point de confiance comme indiqué à l'étape 1. et collez les informations de l'autorité de certification comme décrit à l'étape 4.
5. Dans le champ Certificate Parameters, saisissez les paramètres conformément aux exigences.
6. Dans le champ Clé, vous pouvez utiliser la paire de clés RSA par défaut ou en générer une nouvelle en modifiant le champ Nom de clé.
Remarque : si vous utilisez une autorité de certification Windows, l'extension Stratégies d'application par défaut est IP security IKE intermediaire. Si vous utilisez ce paramètre par défaut, vous devez choisir l'option Ignorer l'utilisation de la clé IPsec dans la section Paramètres avancés de l'onglet Clé de la boîte de dialogue Inscription de certificat PKI pour l'objet que vous choisissez. Sinon, les points d'extrémité ne peuvent pas établir la connexion VPN site à site.
7. Dans le champ Révocation, cochez la case en regard de Consider the Certificate valid if revocation information can not be reached. Aucune vérification CRL ou OCSP n'est utilisée. Cliquez sur Save.
Remarque : si le périphérique peut atteindre les serveurs CRL ou OCSP à partir du FTD, vous pouvez activer la vérification de révocation complète afin d'obtenir l'état du certificat. La case à cocher Considérez le certificat comme valide si les informations de révocation ne peuvent pas être atteintes est activée uniquement lorsqu'il n'y a aucune connectivité entre le serveur CRL et le périphérique FTD. Cette option est cochée par défaut sur le FMC.
8. Ensuite, accédez à Devices > Certificates, cliquez sur Addet choisissez le périphérique FTD et le point de confiance que vous avez créés. Cliquez ensuite sur Add.
9. Vous pouvez vérifier le certificat de l'émetteur en cliquant sur l'icône de la loupe marquée comme CA.
10. Vous obtenez un résultat similaire.
11. À l'étape suivante, vous devez cliquer sur le bouton ID et vous obtenez une fenêtre contextuelle pour générer une CSR. Cliquer Yes.
12. Une fois que vous avez reçu le fichier de certificat d'identité de l'autorité de certification, vous pouvez l'importer à l'aide du Browse Identity Certificate et en cliquant Import.
Remarque : si vous recevez une erreur concernant Import failed due to weak crypto characteristics,utilisez Enable weak-crypto comme indiqué et une fois que vous recevez la fenêtre contextuelle, cliquez sur Oui afin de continuer.
13. Répétez les étapes afin de générer le CSR, et importer le certificat d'identité.
Il n'est pas nécessaire de soumettre à nouveau le CSR, car rien n'a été modifié concernant le périphérique. Vous pouvez importer directement le certificat émis en accédant à l'autorité de certification.
14. Vous pouvez maintenant afficher le certificat d'identité en cliquant sur l'icône de la loupe marquée comme ID.
15. Le certificat a été ajouté.
Configuration VPN
1. Accédez à Devices > Site to Site VPN .
2. Cliquez sur Add > VPN Tunnel.
3. Saisissez le nom de la topologie, qui est un champ obligatoire. Policy based (Crypto Map), Point-to-Point Topology,et IKEv2 sont sélectionnés par défaut et vous devez les utiliser.
4. Dans la section Endpoints, cliquez sur le bouton + en regard de Noeud A.
5. Choisissez le périphérique FTD comme noeud A, et l'interface de terminaison VPN est l'interface externe.
6. Dans le champ Protected Networks, sélectionnez Subnet/IP Address (Network), puis cliquez sur le bouton + s'affiche.
7. Cliquez sur l'icône + en regard de Available Networks.
8. Ici, le réseau ou l’hôte ou la plage d’adresses IP derrière le FTD qui doit être protégé sont définis. Dans ce cas, c'est hostA qui a l'adresse IP 10.106.70.110/32. Cliquer Save.
9. Publiez les messages qui choisissent le nom entré pour l'objet réseau à l'étape précédente et cliquez sur Add. Vous pouvez maintenant voir le nom de l'objet réseau configuré dans les réseaux sélectionnés. Cliquer OK.
10. Vous pouvez maintenant voir votre objet réseau configuré dans la liste Réseaux protégés. Cliquer OK. Le point d'extrémité FTD est maintenant configuré et la configuration côté homologue distant est la suivante.
11. Effectuez le même processus pour le noeud B. Cliquez sur le bouton + en regard de Noeud B.
12. Si le périphérique homologue distant est externe, vous devez choisir le périphérique comme Extranet. Ajoutez le nom du périphérique et son adresse IP publique en tant qu'adresse homologue.
13. Dans le champ Protected Networks, sélectionnez Subnet/IP Address (Network), puis cliquez sur +.
14. Cliquez sur le bouton + en regard de l'icône Available Networks.
15. Entrez l'hôte ou le réseau ou la plage d'adresses IP que vous souhaitez protéger et qui se trouvent derrière le serveur Ubuntu. Dans ce cas, c'est l'hôte B qui a l'adresse IP 10.106.71.110/32. Cliquez sur Save.
16. Publiez les messages qui choisissent le nom entré pour l'objet réseau à l'étape précédente et cliquez sur Add, Vous pouvez maintenant voir le nom de l'objet réseau configuré dans les réseaux sélectionnés. Cliquer OK .
17. Maintenant, vous pouvez voir l'objet réseau configuré dans la liste Réseaux protégés. Click OK.
18. Les terminaux et les réseaux qui doivent être protégés sont maintenant configurés.
19. Ensuite, à partir de la section Endpoints, passez à la section IKE. Modifiez les stratégies sous les paramètres IKEv2 en cliquant sur le bouton Pencil en regard de Stratégies.
20. Dans la section des politiques, Encryption AES, Integrity SHA1, PRF SHA1, DH Group 14 (mod 2048),et FTD-StrongSwan-IKEv2-Phase1 sont utilisées.
21. Laissez la crypto-carte par défaut statique et le mode IKEv2 Tunnel. Dans Jeux de transformations, cliquez sur le bouton Pencil en regard de propositions. Dans les propositions, choisissez Encryption AES, Integrity sha-1,et PFS DH group 14 (2048) comme les propositions dans le FTD-StrongSwan-IPSec.
22. À présent, dans le volet de navigation situé en haut, accédez à Policies > Access Control. Modifiez l'ACP du FTD que vous traitez.
23. Cliquez sur Add Rule.
24. La règle par défaut consiste à bloquer tout le trafic pour permettre un flux de trafic bidirectionnel entre l’hôteA et l’hôteB. Si vous avez configuré des zones, choisissez les zones appropriées et ajoutez-les pour la source et la destination. Cliquez ensuite sur Add .
25. Après avoir ajouté la règle, cliquez sur Save .
26. Enfin, vous devez configurer une instruction No NAT pour que le trafic VPN soit exempté dans le cas où il y a une NAT présente sur le FTD. Naviguez jusqu'à Devices > NAT. Cliquer Add Rule.
27. Ajoutez les objets d’interface appropriés et, sous la section de traduction, choisissez la source d’origine et de traduction comme réseau protégé par VPN derrière le FTD, qui est l’hôte A dans ce cas. De même, pour les destinations Original et Translated, choisissez le réseau protégé par VPN derrière l'extrémité distante, qui est l'hôte B dans ce cas.
28. Dans la section Advanced, assurez-vous de vérifier Do not proxy ARP on Destination Interface et Perform Route Lookup for Destination Interface qui sont nécessaires pour les instructions No NAT.
Configuration de StrongSwan
Obtention du certificat
Toutes les commandes affichées nécessitent des autorisations sudo. Contactez votre administrateur système si vous ne disposez pas des droits d'accès sudo ou des autorisations nécessaires pour installer le logiciel. Des exemples de configuration officiels de StrongSwan sont disponibles ici.
1. Commencez par mettre à jour le cache du package système.
apt update
2. Installez StrongSwan et ses dépendances. Vous pouvez trouver plus d'informations sur les paquets ici.
apt install strongswan strongswan-pki strongswan-swanctl libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins
3. Vérifiez l'état du démon StrongSwan. L'état doit indiquer active(running).
systemctl status strongswan-starter.service
4. Si, pour une raison quelconque, ce n'est pas le cas, activez-le et démarrez-le avec cette commande.
systemctl enable --now strongswan-starter.service
5. Ensuite, utilisez la commande strong-swan pki afin de générer la clé privée et le CSR. Afin de générer une clé privée pour le serveur, exécutez cette commande.
pki --gen > sswan.priv.key
6. Générez des requêtes CSR pour le serveur StrongSwan. Vous pouvez modifier le --dn selon vos besoins.
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. Après avoir fait signer le CSR par l’autorité de certification, copiez le certificat d’émetteur, le certificat d’identité et la clé privée dans le /etc/swanctl répertoire.
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/
Fichier de configuration Swanctl
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
}
}
Vérifier
FTD
1. Vérifiez les paramètres IKEv2 Phase-1.
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. Vérifiez les paramètres de phase 2.
firepower# sh run crypto ipsec
crypto ipsec ikev2 ipsec-proposal CSM_IP_2
protocol esp encryption aes
protocol esp integrity sha-1
3. Vérifiez la configuration de la carte de chiffrement.
Remarque : sur la version FTD 7.2.0, la valeur par défaut PFS is DH Group 14 (MOD 2048). Vous pouvez vérifier la même chose en 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. Vérifiez la liste de contrôle d’accès Crypto.
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. Vérifiez l'état du tunnel.
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. Vérifiez les compteurs 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
StrongSwan
1. Vérifiez les connexions chargées. Si aucune connexion n'est détectée, exécutez la commande 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. Vérifiez le statut SA de l'enfant.
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
Dépannage
FTD
debug crypto condition peer 10.106.67.200
debug crypto ikev2 platfform 127
debug crypto ikev2 protocol 127
debug crypto ipsec 127
La validation de l'ID homologue est activée.
==== 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 ====
StrongSwan
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 [ ]
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
28-Jul-2023 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)