La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come configurare una connessione VPN IKEv2 da sito a sito tra Cisco FTD e StrongSwan utilizzando l'autenticazione di certificazione.
Cisco raccomanda la conoscenza dei seguenti argomenti:
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
In questa configurazione, l'HOST A nella LAN A desidera comunicare con l'HOST B nella LAN B. Il traffico deve essere crittografato e inviato su un tunnel IKEv2 tra FTD e il server Ubuntu con StrongSwan. Entrambi i peer vengono autenticati reciprocamente con l'autenticazione certificato.
1. Dal CCP passare a Objects > Object Management > PKI > Cert Enrollment
.
2. Fare clic su Add Cert Enrollment
.
3. La sezione Nome è un campo obbligatorio; assegnare un nome al Trustpoint.
4. Viene utilizzata l'iscrizione manuale dei certificati. Nella scheda delle informazioni della CA incollare il certificato dell'autorità emittente.
Nota: se non si dispone di un certificato dell'autorità emittente, è possibile continuare a generare CSR senza il certificato. Dopo aver firmato il CSR dall'autorità di certificazione, modificare il trust point come indicato nel passaggio 1 e incollare le informazioni sull'autorità di certificazione come descritto nel passaggio 4.
5. Nel campo Parametri certificato, inserire i parametri in base al fabbisogno.
6. Nel campo Key (Chiave), è possibile usare la coppia di chiavi RSA predefinita o generarne una nuova modificando il campo Key Name (Nome chiave).
Nota: se si utilizza una CA (Certification Authority) di Windows, l'estensione predefinita dei criteri di applicazione è IP Security IKE intermediate. Se si utilizza questa impostazione predefinita, è necessario scegliere l'opzione Ignora utilizzo chiave IPSec nella sezione Impostazioni avanzate della scheda Chiave della finestra di dialogo Registrazione certificato PKI per l'oggetto scelto. In caso contrario, gli endpoint non potranno completare la connessione VPN da sito a sito.
7. Nel campo Revoca, scegliere la casella di controllo accanto a Consider the Certificate valid if revocation information can not be reached
. Non vengono utilizzati controlli CRL o OCSP. Fare clic su Salva.
Nota: se il dispositivo è in grado di raggiungere i server CRL o OCSP dall'FTD, è possibile abilitare il controllo esteso delle revoche per ottenere lo stato del certificato. La casella di controllo Considera il certificato valido se le informazioni di revoca non possono essere raggiunte è abilitata solo quando non è disponibile alcuna connettività tra il server CRL e il dispositivo FTD. Questa opzione è selezionata per impostazione predefinita nel CCP.
8. Passare quindi a Devices > Certificates
,fare clic su Add
e scegliere il dispositivo FTD e il Trustpoint creato. Quindi, fare clic su Add
.
9. È possibile controllare il certificato dell'emittente facendo clic sull'icona della lente di ingrandimento contrassegnata come CA
.
10. Si ottiene un risultato simile.
11. Nel passaggio successivo, è necessario fare clic sul pulsante ID
e si ottiene un popup per generare un CSR. Fare clic su Yes
.
12. Una volta ottenuto il file del certificato di identità dalla CA, è possibile importarlo utilizzando il comando Browse Identity Certificate
e facendo clic Import
.
Nota: se viene visualizzato un errore relativo a Import failed due to weak crypto characteristics
, utilizzare il Enable weak-crypto
come mostrato e una volta ricevuto il messaggio popup, fare clic su Sì per continuare.
13. Ripetere i passaggi per generare la richiesta di supporto e importare il certificato di identità.
Non è necessario inviare di nuovo il CSR poiché non è stato modificato nulla relativo al dispositivo. È possibile importare direttamente il certificato rilasciato passando alla CA.
14. È ora possibile visualizzare il certificato di identità facendo clic sull'icona a forma di lente di ingrandimento contrassegnata come ID
.
15. Il certificato è stato aggiunto correttamente.
1. Passare a Devices > Site to Site VPN
.
2. Fare clic su Add > VPN Tunnel
.
3. Inserire il nome della topologia che è un campo obbligatorio. Policy based (Crypto Map)
, Point-to-Point Topology
,e IKEv2
sono selezionate per default ed è necessario utilizzarle.
4. Nella sezione Endpoints, fare clic sul pulsante +
accanto al Nodo A.
5. Scegliere il dispositivo FTD come Nodo A e l'interfaccia di terminazione VPN è l'interfaccia esterna.
6. Nel campo Reti protette, scegliere la subnet/indirizzo IP (rete), quindi fare clic sul pulsante +
Icona.
7. Fare clic sull'icona + accanto a Available Networks
.
8. Qui sono definiti la rete, l'host o l'intervallo di indirizzi IP dietro l'FTD che deve essere protetto. In questo caso, è l'hostA a avere l'indirizzo IP 10.106.70.110/32. Fare clic su Save
.
9. Contabilizzare che scelga il nome inserito per l'oggetto di rete nel passo precedente e fare clic su Add
. È ora possibile visualizzare il nome dell'oggetto di rete configurato in Reti selezionate. Fare clic su OK
.
10. È ora possibile visualizzare il nostro oggetto di rete configurato nell'elenco delle reti protette. Fare clic su OK
. L'endpoint FTD è ora configurato e la configurazione remota peer-side successiva.
11. Eseguire lo stesso processo per il nodo B. Fare clic sul pulsante +
accanto al Nodo B.
12. Se il dispositivo peer remoto è esterno, è necessario scegliere il dispositivo come Extranet. Aggiungere il nome del dispositivo e il relativo indirizzo IP pubblico come indirizzo peer.
13. Nel campo Reti protette, scegliere la subnet/indirizzo IP (rete) e fare clic su +
.
14. Fare clic sul pulsante +
accanto a Reti disponibili.
15. Immettere l'host, la rete o l'intervallo di indirizzi IP da proteggere che si trovano dietro il server Ubuntu. In questo caso, è l'host B a avere l'indirizzo IP 10.106.71.110/32. Fare clic su Salva.
16. Contabilizzazione che sceglie il Nome inserito per l'oggetto di rete nel passo precedente e fare clic su Add
, è ora possibile visualizzare il nome dell'oggetto di rete configurato in Reti selezionate. Fare clic su OK
.
17. È ora possibile visualizzare l'oggetto di rete configurato nell'elenco Reti protette. Fare clic su OK.
18. A questo punto, gli endpoint e le reti da proteggere sono configurati.
19. Successivamente, dalla sezione Endpoints, si passerà alla sezione IKE. Modificare i criteri in Impostazioni IKEv2 facendo clic sul pulsante Pencil
accanto a Criteri.
20. Nella sezione politiche, Encryption AES
, Integrity SHA1
, PRF SHA1
, DH Group 14 (mod 2048)
,e FTD-StrongSwan-IKEv2-Phase1
utilizzati.
21. Lasciare la mappa crittografica predefinita statica e la modalità IKEv2 tunnel. In Set di trasformazioni, fare clic sul pulsante Pencil
accanto a proposte. Nelle proposte, scegliere Encryption AES
,
Integrity sha-1
,e PFS DH group 14 (2048)
come le proposte contenute nel documento FTD-StrongSwan-IPSec.
22. Dal riquadro di navigazione in alto, passare a Policies > Access Control
. Modificare il punto ACP per l'FTD che si sta utilizzando.
23. Fare clic Add Rule
.
24. Per impostazione predefinita, il traffico viene bloccato per consentire il flusso bidirezionale del traffico tra l'host A e l'host B. Se sono state configurate zone, scegliere quelle appropriate e aggiungerle per origine e destinazione. Quindi fare clic su Add
.
25. Dopo aver aggiunto la regola, fare clic su Save
.
26. Infine, è necessario configurare un'istruzione No NAT per il traffico VPN da esentare nel caso in cui sia presente un NAT sull'FTD. Passa a Devices > NAT
. Fare clic su Add Rule
.
27. Aggiungere gli oggetti dell'interfaccia e sotto la sezione di traduzione scegliere Originale e Tradotto come la rete VPN protetta dietro l'FTD, che in questo caso è hostA. Analogamente, per le destinazioni Original e Translated, scegliere la rete protetta da VPN dietro l'estremità remota, che in questo caso è hostB.
28. Nella sezione Avanzate, assicurarsi di controllare Do not proxy ARP on Destination Interface
e Perform Route Lookup for Destination Interface
caselle di controllo, necessarie per le istruzioni No NAT.
Tutti i comandi visualizzati richiedono autorizzazioni sudo. Se non si dispone dell'accesso sudo o delle autorizzazioni necessarie per installare il software, contattare l'amministratore di sistema. Qui è possibile trovare configurazioni ufficiali di esempio di StrongSwan.
1. Iniziare aggiornando la cache dei pacchetti di sistema.
apt update
2. Installare StrongSwan e le relative dipendenze. Qui sono disponibili ulteriori informazioni sui pacchetti.
apt install strongswan strongswan-pki strongswan-swanctl libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins
3. Controllare lo stato del daemon StrongSwan. Lo stato deve essere attivo (in esecuzione).
systemctl status strongswan-starter.service
4. In caso contrario, abilitarlo e avviarlo con questo comando.
systemctl enable --now strongswan-starter.service
5. Quindi, utilizzare il strong-swan pki
dello strumento da riga di comando per generare la chiave privata e il CSR. Per generare una chiave privata per il server, eseguire questo comando.
pki --gen > sswan.priv.key
6. Generare richieste CSR per il server StrongSwan. È possibile modificare --dn
in base alle proprie esigenze.
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. Dopo aver ottenuto il CSR firmato dalla CA, copiare il certificato dell'autorità emittente, il certificato di identità e la chiave privata nel rispettivo /etc/swanctl
directory.
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. Controllare i parametri IKEv2 fase 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. Controllare i parametri della 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. Controllare la configurazione della mappa crittografica.
Nota: nella versione FTD 7.2.0 l'impostazione di default PFS is DH Group 14 (MOD 2048)
. È possibile verificare lo stesso 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. Controllare l'ACL della crittografia.
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. Controllare lo stato del 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. Controllare i contatori 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. Controllare le connessioni caricate. Se non vengono rilevate connessioni, eseguire il comando 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. Controllare lo stato SA del figlio.
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
Convalida ID peer attivata.
==== 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 [ ]
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
28-Jul-2023 |
Versione iniziale |