Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Esempio di rete

Configurazione

Configurare la VPN su accesso sicuro

Dati per configurazione tunnel

Configurare il tunnel su Secure Firewall

Configurazione dell'interfaccia del tunnel

Configura route statica per l'interfaccia secondaria

Configurare la VPN per l'accesso sicuro in modalità VTI

Configurazione degli endpoint

Configurazione IKE

Configurazione IPSEC

Configurazione avanzata

Scenari di configurazione dei criteri di accesso

Scenario di accesso Internet

RA-VPN Escenario

CLAP-BAP ZTNA Escenario

Configura Policy Base Routing

Configura i criteri di accesso a Internet per l'accesso protetto

Configurazione dell'accesso alle risorse private per ZTNA e RA-VPN

Risoluzione dei problemi

Verifica fase 1 (IKEv2)

Verifica fase 2 (IPSEC)

Funzione High Availability

Verifica del routing del traffico per l'accesso sicuro

Informazioni correlate

Introduzione

In questo documento viene descritto come configurare Secure Access con Secure Firewall con alta disponibilità.

Prerequisiti

- Configura assegnazione ruoli utente

- Configurazione autenticazione SSO ZTNA

- Configura accesso sicuro VPN di accesso remoto

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- Firepower Management Center 7.2

- Firepower Threat Defense 7.2

- Accesso sicuro

- Cisco Secure Client - VPN

- Cisco Secure Client - ZTNA

- ZTNA senza client

Componenti usati

Le informazioni fornite in questo documento si basano su:

- Firepower Management Center 7.2

- Firepower Threat Defense 7.2

- Accesso sicuro

- Cisco Secure Client - VPN

- Cisco Secure Client - ZTNA

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.

Premesse

Cisco ha progettato Secure Access per proteggere e fornire accesso alle applicazioni private, sia in sede che basate su cloud. Inoltre, garantisce il collegamento dalla rete a Internet. Questo risultato è ottenuto attraverso l'implementazione di più metodi e livelli di sicurezza, il tutto finalizzato a preservare le informazioni mentre vi accedono tramite il cloud.

Esempio di rete

Configurazione

Configurare la VPN su accesso sicuro

Passare al pannello di amministrazione di Accesso sicuro.

- Fare clic su Connect > Network Connections

- In fareNetwork Tunnel Groupsclic su + Add

- ConfigurazioneTunnel Group Name, RegioneDevice Type

- Fare clic su  Next

- ConfigurareTunnel ID Formate Passphrase

- Fare clic su Next

- Configurare gli intervalli di indirizzi IP o gli host configurati nella rete e che si desidera passare il traffico attraverso l'accesso sicuro

- Fare clic su Save

Dopo aver fatto clic sulle informazioni relative al Save tunnel che vengono visualizzate, salvarle per il passaggio successivo, Configure the tunnel on Secure Firewall.

Dati per configurazione tunnel

Configurare il tunnel su Secure Firewall

Configurazione dell'interfaccia del tunnel

Per questo scenario, è necessario utilizzare la configurazione VTI (Virtual Tunnel Interface) su Secure Firewall; in questo caso, si dispone di un doppio ISP e si desidera avere HA se uno dei propri ISP ha esito negativo.

INTERFACCE

RUOLO

PrimaryWAN

Principal Internet WAN

Secondary WAN

WAN Internet secondaria

PrimaryVTI

Collegato per inviare il traffico attraverso il Principal Internet WAN router ad accesso protetto

VTI secondario

Collegato per inviare il traffico attraverso il Secondary Internet WAN router ad accesso protetto

Nota: 1. Per avere entrambi i tunnel, è necessario aggiungere o assegnare un percorso statico alla Primary or Secondary Datacenter IP rete.

Nota: 2. Se l'ECMP è stato configurato tra le interfacce, non è necessario creare un percorso statico all'Primary or Secondary Datacenter IPinterfaccia per poter avere entrambi i tunnel attivi.

In base allo scenario, abbiamo PrimaryWAN e SecondaryWAN, che dobbiamo utilizzare per creare le interfacce VTI.

Passare allaFirepower Management Center > Devicespagina.

- Scegli il tuo FTD

- Scegli Interfaces

- Fare clic su Add Interfaces > Virtual Tunnel Interface

- Configurare l'interfaccia in base alle informazioni seguenti

- Name : Configurare un nome che faccia riferimento al PrimaryWAN interface

- Security Zone : È possibile riutilizzarne un altro Security Zonema è preferibile crearne uno nuovo per il traffico di accesso sicuro

- Tunnel ID : Aggiungere un numero per l'ID tunnel

- Tunnel Source : Scegliere l'indirizzo IP pubblico o privato PrimaryWAN interface dell'interfaccia

- IPsec Tunnel Mode : Selezionare IPv4 e configurare un indirizzo IP non instradabile nella rete con la maschera 30

Nota: Per l'interfaccia VTI, è necessario usare un indirizzo IP non instradabile; ad esempio, se si hanno due interfacce VTI, è possibile usare 169.254.2.1/30 per PrimaryVTI e 169.254.3.1/30 per SecondaryVTI.

In seguito, è necessario eseguire la stessa operazione per il SecondaryWAN interfaceVTI e tutte le impostazioni sono configurate per l'alta disponibilità VTI, con il risultato seguente:

Per questo scenario, vengono utilizzati i seguenti IP:

Configurazione IP VTI

Nome logico

IP

Intervallo

PrimaryVTI

169.254.2.1/30

169.254.2.1-169.254.2.2

VTI secondario

169.254.3.1/30

169.254.3.1-169.254.3.2

Configura route statica per l'interfaccia secondaria

Per consentire al traffico del SecondaryWAN interface router di raggiungere l'Secondary Datacenter IP Addresshost, è necessario configurare una route statica all'indirizzo IP del centro dati. È possibile configurarla con una metrica di uno (1) per collocarla sopra la tabella di routing; inoltre, specificare l'indirizzo IP come host.

Attenzione: Questa operazione è necessaria solo se non si dispone di una configurazione ECMP tra i canali WAN; se è stato configurato ECMP, è possibile passare alla fase successiva.

Passa a Device > Device Management

- Fare clic sul dispositivo FTD

- Fare clic su Routing

- Scegli Static Route > + Add Route

- Interface: Scelta dell'interfaccia WAN secondaria

- Gateway: Scelta del gateway WAN secondario

- Selected Network: Aggiungere l'indirizzo IP del centro dati secondario come host; le informazioni sono reperibili nella procedura di configurazione del tunnel su accesso sicuro, Dati per configurazione tunnel

- Metric: Usa uno (1)

- OKFare clic su and Save per salvare le informazioni, quindi su deploy (distribuisci).

Configurare la VPN per l'accesso sicuro in modalità VTI

Per configurare la VPN, passare al firewall:

- Fare clic su Devices > Site to Site

- Fare clic su + Site to Site VPN

Configurazione degli endpoint

Per configurare il passaggio Endpoint, è necessario utilizzare le informazioni fornite nel passaggio Dati per configurazione tunnel.

- Nome topologia: Crea un nome correlato all'integrazione di Accesso sicuro

- Scegli Routed Based (VTI)

- Scegli Point to Point

- IKE Version: Scegli IKEv2

Nota: IKEv1 non è supportato per l'integrazione con Secure Access.

In è Node Anecessario configurare i parametri successivi:

- Device: Scegli il dispositivo FTD

- Virtual Tunnel Interface: Scegliere la VTI correlata alla PrimaryWAN InterfaceVLAN.

- Selezionare la casella di controllo Send Local Identity to Peers

- Local Identity Configuration: Scegliere l'ID e-mail e immettere le informazioni in base a quanto Primary Tunnel ID fornito nella configurazione nella fase Data for Tunnel Setup

Dopo aver configurato le informazioni sul PrimaryVTI clic su + Add Backup VTI:

- Virtual Tunnel Interface: Scegliere la VTI correlata alla PrimaryWAN InterfaceVLAN.

- Selezionare la casella di controllo Send Local Identity to Peers

- Local Identity Configuration: Scegliere l'ID e-mail e immettere le informazioni in base a quanto Secondary Tunnel ID fornito nella configurazione nella fase Data for Tunnel Setup

In è Node Bnecessario configurare i parametri successivi:

- Device: Extranet

- Device Name: Scegliere un Nome per riconoscere Accesso protetto come destinazione.

- Endpoint IP Address: La configurazione per primario e secondario deve essere Primario Datacenter IP,Secondary Datacenter IP. Queste informazioni sono disponibili nel passo Dati per configurazione tunnel

Al termine, la configurazione di Endpoints è stata completata ed è ora possibile passare alla fase Configurazione IKE.

Configurazione IKE

Per configurare i parametri IKE, fare clic su IKE.

In è IKE, necessario configurare i parametri successivi:

- Policies: È possibile utilizzare la configurazione Umbrella predefinita Umbrella-AES-GCM-256 oppure configurare parametri diversi in base alla Supported IKEv2 and IPSEC Parameters

- Authentication Type: Chiave manuale già condivisa

- Keye:Confirm Key Le informazioni sono disponibili nel Passphrase passo Dati per configurazione tunnel

Al termine, la configurazione di IKE è stata completata ed è ora possibile passare alla fase Configurazione IPSEC.

Configurazione IPSEC

Per configurare i parametri IPSEC, fare clic su IPSEC.

In è IPSEC, necessario configurare i parametri successivi:

- Policies: È possibile utilizzare la configurazione Umbrella predefinita Umbrella-AES-GCM-256 oppure configurare parametri diversi in base alla Supported IKEv2 and IPSEC Parameters

Nota: Su IPSEC non è richiesto altro.

Al termine, la configurazione di IPSEC è stata completata ed è ora possibile passare alla fase Configurazione avanzata.

Configurazione avanzata

Per configurare i parametri avanzati, fare clic su Avanzate.

In è Advanced, necessario configurare i parametri successivi:

- IKE Keepalive: Abilita

- Threshold: 10

- Retry Interval: 2

- Identity Sent to Peers: AutoOrDN

- Peer Identity Validation: Non controllare

Dopodiché, è possibile fare clic suSavee su Deploy.

Nota: Dopo alcuni minuti, verrà visualizzata la VPN stabilita per entrambi i nodi.

Al termine, la configurazione del VPN to Secure Access in VTI Mode file è stata completata ed è possibile procedere alla procedura Configure Policy Base Routing.

Avviso: il traffico diretto all'accesso sicuro viene inoltrato solo al tunnel primario quando sono stabiliti entrambi i tunnel; se il server primario non è attivo, Secure Access consente l'inoltro del traffico attraverso il tunnel secondario.

Nota: il failover sul sito Secure Access è basato sui valori DPD documentati nella guida per l'utente per i valori IPsec supportati.

Scenari di configurazione dei criteri di accesso

Le regole dei criteri di accesso definite si basano su:

Interfaccia

Zona

PrimaryVTI

SIG

VTI secondario

SIG

LAN

LAN

Scenario di accesso Internet

Per consentire l'accesso a Internet a tutte le risorse configurate nel Policy Base Routing, è necessario configurare alcune regole di accesso e alcuni criteri in accesso sicuro. In questo scenario verranno illustrate le modalità per ottenere questo risultato:

Questa regola fornisce l'accesso a LAN Internet e, in questo caso, Internet è SIGprotetto.

RA-VPN Escenario

Per fornire l'accesso dagli utenti RA-VPN, è necessario configurarlo in base all'intervallo assegnato al pool RA-VPN.

Nota: Per configurare il criterio RA-VPNaaS, è possibile passare alla sezione Gestione reti private virtuali

Come è possibile verificare il pool IP della VPNaaS?

Passare al Dashboard di accesso protetto

- Fare clic su Connect > End User Connectivity

- Fare clic su Virtual Private Network

- In Manage IP Pools, fare clic su Manage

- Vedi la tua piscina sotto Endpoint IP Pools

- È necessario autorizzare questo intervallo in SIG, ma è necessario aggiungerlo anche nell'ACL configurato nel PBR.

Configurazione regola di accesso

Se si configura Accesso sicuro solo per utilizzarlo con le funzionalità di accesso alle risorse delle applicazioni private, la regola di accesso può avere il seguente aspetto:

Questa regola consente il traffico dal pool RA-VPN 192.168.50.0/24 alla rete LAN; se necessario, è possibile specificare altre opzioni.

Configurazione ACL

Per consentire il routing del traffico da SIG alla LAN, è necessario aggiungerlo all'ACL in modo che funzioni nel PBR.

CLAP-BAP ZTNA Escenario

È necessario configurare la rete in base all'intervallo CGNAT 100.64.0.0/10 per consentire l'accesso alla rete da parte degli utenti ZTA di base client o ZTA di base browser.

Configurazione regola di accesso

Se si configura Accesso sicuro solo per utilizzarlo con le funzionalità di accesso alle risorse delle applicazioni private, la regola di accesso può avere il seguente aspetto:

Questa regola consente il traffico dall'intervallo CGNAT ZTNA 100.64.0.0/10 alla LAN.

Configurazione ACL

Per consentire il routing del traffico da SIG alla LAN tramite CGNAT, è necessario aggiungerlo nell'ACL in modo che funzioni nel PBR.

Configura Policy Base Routing

Per consentire l'accesso alle risorse interne e a Internet tramite l'accesso sicuro, è necessario creare route tramite Policy Base Routing (PBR) che facilitino il routing del traffico dall'origine alla destinazione.

- Passa a Devices > Device Management

- Scegliere il dispositivo FTD in cui creare il ciclo di lavorazione

- Fare clic su Routing

- Scegli Policy Base Routing

- Fare clic su Add

In questo scenario, è possibile selezionare tutte le interfacce utilizzate come origine per instradare il traffico verso l'accesso sicuro o per fornire l'autenticazione utente all'accesso sicuro mediante RA-VPN o l'accesso ZTA basato su client o browser alle risorse interne della rete:

- In Interfaccia in ingresso selezionare tutte le interfacce che inviano il traffico tramite l'accesso sicuro:

- In Criteri di corrispondenza e interfaccia in uscita (Match Criteria and Egress Interface), definite i parametri successivi dopo aver fatto clic suAdd:

- Match ACL: Per questo ACL, è possibile configurare tutti gli elementi indirizzati a Secure Access:

- Send To: Scegli indirizzo IP

- IPv4 Addresses: È necessario usare l'IP successivo sotto la maschera 30 configurata su entrambe le VTI; è possibile controllare che al di sotto della fase, VTI Interface Config

Interfaccia

IP

GW

PrimaryVTI

169.254.2.1/30

169.254.2.2

VTI secondario

169.254.3.1/30

169.254.3.2

Dopo aver configurato il file in questo modo, si otterrà il risultato successivo e sarà possibile fare clic su Save:

Dopo di che, è necessario Save di nuovo e lo avete configurato nel modo seguente:

Quindi, è possibile eseguire la distribuzione e visualizzare il traffico dei computer configurati sull'ACL che instrada il traffico a Secure Access:

Dal Conexion Events CCP:

Dalla Activity Search scheda in Accesso sicuro:

Nota: Per impostazione predefinita, i criteri di accesso protetto predefiniti consentono il traffico verso Internet. Per consentire l'accesso alle applicazioni private, è necessario creare risorse private e aggiungerle ai criteri di accesso per l'accesso alle risorse private.

Configura i criteri di accesso a Internet per l'accesso protetto

Per configurare l'accesso per l'accesso a Internet, è necessario creare il criterio nel Dashboard di accesso sicuro:

- Fare clic su Secure > Access Policy

- Fare clic su Add Rule > Internet Access

In questa finestra è possibile specificare l'origine come tunnel e la destinazione come destinazione è possibile scegliere qualsiasi, a seconda di ciò che si desidera configurare in base al criterio. Consultare la Guida dell'utente di Secure Access.

Configurazione dell'accesso alle risorse private per ZTNA e RA-VPN

Per configurare l'accesso per le risorse private, è necessario innanzitutto creare le risorse nel Dashboard accesso sicuro:

Fare clic su Resources > Private Resources

- Quindi fare clic su ADD

Nella configurazione sono disponibili le sezioni successive da configurare: General, Communication with Secure Access Cloud and Endpoint Connection Methods.

Informazioni generali

- Private Resource Name : Creare un nome per la risorsa alla quale si fornisce l'accesso tramite l'accesso sicuro alla rete

Metodi di connessione degli endpoint

- Zero Trust Connections: Contrassegnare la casella di controllo.

- Client-based connection: Se viene attivato, è possibile utilizzare il modulo Secure Client - Zero Trust per abilitare l'accesso tramite la modalità basata su client.

- Remote Reachable Address (FQDN, Wildcard FQDN, IP Address) : Configurare l'indirizzo IP o FQDN delle risorse. se si configura FQDN, è necessario aggiungere il DNS per risolvere il nome.

- Browser-based connection: se la si abilita, sarà possibile accedere alle risorse tramite browser (aggiungere solo risorse con comunicazione HTTP o HTTPS)

- Public URL for this resource: Configurare l'URL pubblico da utilizzare con il browser; La risorsa è protetta da Accesso sicuro.

- Protocol: Selezionare il protocollo (HTTP o HTTPS)

VPN Connection: Selezionare la casella di controllo per abilitare l'accesso tramite RA-VPNaaS.

Quindi, fare clic su Save per aggiungere la risorsa alla Access Policycartella.

Configurare i criteri di accesso

Quando si crea la risorsa, è necessario assegnarla a uno dei criteri di accesso sicuro:

- Fare clic su Secure > Access Policy

- Fare clic su  Add > Private Resource

Per questa regola di accesso privato è necessario configurare i valori predefiniti per consentire l'accesso alla risorsa. Per ulteriori informazioni sulle configurazioni dei criteri, consultare la Guida dell'utente.

- Action : Scegliere Consenti per consentire l'accesso alla risorsa.

- From : Specificare l'utente che può essere utilizzato per accedere alla risorsa.

- To : Scegliere la risorsa a cui si desidera accedere tramite Accesso protetto.

- Zero-Trust Client-based Posture Profile: Scegliere il profilo predefinito per l'accesso alla base client

- Zero-Trust Browser-based Posture Profile: Scegliere l'accesso di base predefinito al browser dei profili

Nota: Per ulteriori informazioni sui criteri di postura, consultare la guida dell'utente per l'accesso sicuro.

Quindi, fare clic su Next andSave e sulla configurazione, quindi provare ad accedere alle risorse tramite RA-VPN e Client Base ZTNA o Browser Base ZTNA.

Risoluzione dei problemi

Per risolvere i problemi in base alla comunicazione tra Secure Firewall e Secure Access, è possibile verificare se la fase 1 (IKEv2) e la fase 2 (IPSEC) sono state stabilite tra i dispositivi senza alcun problema.

Verifica fase 1 (IKEv2)

Per verificare la fase 1, è necessario eseguire il comando successivo sulla CLI dell'FTD:

show crypto isakmp sa

In questo caso, l'output desiderato è due IKEv2 SAs stabilito per gli indirizzi IP dei data center di accesso sicuro e lo stato desiderato come READY:

There are no IKEv1 SAs

IKEv2 SAs:

Session-id:3, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local                                               Remote                                     fvrf/ivrf     Status         Role

52346451 192.168.0.202/4500                                  3.120.45.23/4500                        Global/Global      READY    RESPONDER

Encr: AES-GCM, keysize: 256, Hash: N/A, DH Grp:20, Auth sign: PSK, Auth verify: PSK

Life/Active Time: 86400/4009 sec

Child sa: local selector  0.0.0.0/0 - 255.255.255.255/65535

remote selector 0.0.0.0/0 - 255.255.255.255/65535

ESP spi in/out: 0xfb34754c/0xc27fd2ba

IKEv2 SAs:

Session-id:2, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local                                               Remote                                     fvrf/ivrf     Status         Role

52442403 192.168.30.5/4500                                   18.156.145.74/4500                      Global/Global      READY    RESPONDER

Encr: AES-GCM, keysize: 256, Hash: N/A, DH Grp:20, Auth sign: PSK, Auth verify: PSK

Life/Active Time: 86400/3891 sec

Child sa: local selector  0.0.0.0/0 - 255.255.255.255/65535

remote selector 0.0.0.0/0 - 255.255.255.255/65535

ESP spi in/out: 0x4af761fd/0xfbca3343

Verifica fase 2 (IPSEC)

Per verificare la fase 2, è necessario eseguire il comando successivo sulla CLI dell'FTD:

interface: PrimaryVTI

Crypto map tag: __vti-crypto-map-Tunnel1-0-1, seq num: 65280, local addr: 192.168.30.5

Protected vrf (ivrf): Global

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

current_peer: 18.156.145.74

#pkts encaps: 71965, #pkts encrypt: 71965, #pkts digest: 71965

#pkts decaps: 91325, #pkts decrypt: 91325, #pkts verify: 91325

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 71965, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#TFC rcvd: 0, #TFC sent: 0

#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: 192.168.30.5/4500, remote crypto endpt.: 18.156.145.74/4500

path mtu 1500, ipsec overhead 63(44), media mtu 1500

PMTU time remaining (sec): 0, DF policy: copy-df

ICMP error validation: disabled, TFC packets: disabled

current outbound spi: FBCA3343

current inbound spi : 4AF761FD

inbound esp sas:

spi: 0x4AF761FD (1257726461)

SA State: active

transform: esp-aes-gcm-256 esp-null-hmac no compression

in use settings ={L2L, Tunnel,  NAT-T-Encaps, IKEv2, VTI, }

slot: 0, conn_id: 2, crypto-map: __vti-crypto-map-Tunnel1-0-1

sa timing: remaining key lifetime (kB/sec): (3916242/27571)

IV size: 8 bytes

replay detection support: Y

Anti replay bitmap:

0xFFFFFFFF 0xFFFFFFFF

outbound esp sas:

spi: 0xFBCA3343 (4224332611)

SA State: active

transform: esp-aes-gcm-256 esp-null-hmac no compression

in use settings ={L2L, Tunnel,  NAT-T-Encaps, IKEv2, VTI, }

slot: 0, conn_id: 2, crypto-map: __vti-crypto-map-Tunnel1-0-1

sa timing: remaining key lifetime (kB/sec): (4239174/27571)

IV size: 8 bytes

replay detection support: Y

Anti replay bitmap:

0x00000000 0x00000001

interface: SecondaryVTI

Crypto map tag: __vti-crypto-map-Tunnel2-0-2, seq num: 65280, local addr: 192.168.0.202

Protected vrf (ivrf): Global

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

current_peer: 3.120.45.23

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#TFC rcvd: 0, #TFC sent: 0

#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0

#send errors: 0, #recv errors: 0

local crypto endpt.: 192.168.0.202/4500, remote crypto endpt.: 3.120.45.23/4500

path mtu 1500, ipsec overhead 63(44), media mtu 1500

PMTU time remaining (sec): 0, DF policy: copy-df

ICMP error validation: disabled, TFC packets: disabled

current outbound spi: C27FD2BA

current inbound spi : FB34754C

inbound esp sas:

spi: 0xFB34754C (4214519116)

SA State: active

transform: esp-aes-gcm-256 esp-null-hmac no compression

in use settings ={L2L, Tunnel,  NAT-T-Encaps, IKEv2, VTI, }

slot: 0, conn_id: 20, crypto-map: __vti-crypto-map-Tunnel2-0-2

sa timing: remaining key lifetime (kB/sec): (4101120/27412)

IV size: 8 bytes

replay detection support: Y

Anti replay bitmap:

0x00000000 0x00000001

outbound esp sas:

spi: 0xC27FD2BA (3263156922)

SA State: active

transform: esp-aes-gcm-256 esp-null-hmac no compression

in use settings ={L2L, Tunnel,  NAT-T-Encaps, IKEv2, VTI, }

slot: 0, conn_id: 20, crypto-map: __vti-crypto-map-Tunnel2-0-2

sa timing: remaining key lifetime (kB/sec): (4239360/27412)

IV size: 8 bytes

replay detection support: Y

Anti replay bitmap:

0x00000000 0x00000001

Nell'ultimo output, è possibile vedere entrambi i tunnel stabiliti; ciò che non si desidera è l'output successivo sotto il pacchettoencapsedecaps.

In questo caso, aprire una richiesta con TAC.

Funzione High Availability

La funzione dei tunnel con accesso sicuro che comunicano con il centro dati nel cloud è attiva/passiva, il che significa che solo la porta per DC 1 sarà aperta per ricevere il traffico; lo sportello CC 2 è chiuso finché non scende il tunnel numero 1.

Verifica del routing del traffico per l'accesso sicuro

In questo esempio, viene utilizzata l'origine come computer sulla rete del firewall:

- Fonte: 192.168.10.40

- Destinazione: 146.112.255.40 (Secure Access Monitoring IP)

Esempio:

Comando:

packet-tracer input LAN tcp 192.168.10.40 3422 146.112.255.40 80

Uscita:

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Elapsed time: 14010 ns

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: PBR-LOOKUP

Subtype: policy-route

Result: ALLOW

Elapsed time: 21482 ns

Config:

route-map FMC_GENERATED_PBR_1707686032813 permit 5

match ip address ACL

set ip next-hop 169.254.2.2 169.254.3.2

Additional Information:

Matched route-map FMC_GENERATED_PBR_1707686032813, sequence 5, permit

Found next-hop 169.254.2.2 using egress ifc PrimaryVTI

Phase: 3

Type: OBJECT_GROUP_SEARCH

Subtype:

Result: ALLOW

Elapsed time: 0 ns

Config:

Additional Information:

Source Object Group Match Count:       0

Destination Object Group Match Count:  0

Object Group Search:                   0

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Elapsed time: 233 ns

Config:

access-group CSM_FW_ACL_ global

access-list CSM_FW_ACL_ advanced permit ip any ifc PrimaryVTI any rule-id 268434435

access-list CSM_FW_ACL_ remark rule-id 268434435: ACCESS POLICY: HOUSE - Mandatory

access-list CSM_FW_ACL_ remark rule-id 268434435: L7 RULE: New-Rule-#3-ALLOW

Additional Information:

This packet will be sent to snort for additional processing where a verdict will be reached

Phase: 5

Type: CONN-SETTINGS

Subtype:

Result: ALLOW

Elapsed time: 233 ns

Config:

class-map class_map_Any

match access-list Any

policy-map policy_map_LAN

class class_map_Any

set connection decrement-ttl

service-policy policy_map_LAN interface LAN

Additional Information:

Phase: 6

Type: NAT

Subtype: per-session

Result: ALLOW

Elapsed time: 233 ns

Config:

Additional Information:

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Elapsed time: 233 ns

Config:

Additional Information:

Phase: 8

Type: VPN

Subtype: encrypt

Result: ALLOW

Elapsed time: 18680 ns

Config:

Additional Information:

Phase: 9

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Elapsed time: 25218 ns

Config:

Additional Information:

Phase: 10

Type: NAT

Subtype: per-session

Result: ALLOW

Elapsed time: 14944 ns

Config:

Additional Information:

Phase: 11

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Elapsed time: 0 ns

Config:

Additional Information:

Phase: 12

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Elapsed time: 19614 ns

Config:

Additional Information:

New flow created with id 23811, packet dispatched to next module

Phase: 13

Type: EXTERNAL-INSPECT

Subtype:

Result: ALLOW

Elapsed time: 27086 ns

Config:

Additional Information:

Application: 'SNORT Inspect'

Phase: 14

Type: SNORT

Subtype: appid

Result: ALLOW

Elapsed time: 28820 ns

Config:

Additional Information:

service: (0), client: (0), payload: (0), misc: (0)

Phase: 15

Type: SNORT

Subtype: firewall

Result: ALLOW

Elapsed time: 450193 ns

Config:

Network 0, Inspection 0, Detection 0, Rule ID 268434435

Additional Information:

Starting rule matching, zone 1 -> 3, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, no url or host, no xff

Matched rule ids 268434435 - Allow

Result:

input-interface: LAN(vrfid:0)

input-status: up

input-line-status: up

output-interface: PrimaryVTI(vrfid:0)

output-status: up

output-line-status: up

Action: allow

Time Taken: 620979 ns

In questo caso, molte cose possono fornire un contesto relativo alla comunicazione e sapere se tutto è correttamente nella configurazione PBR per indirizzare correttamente il traffico verso Secure Access:

La fase 2 indica che il traffico viene inoltrato all'PrimaryVTIinterfaccia, e questa operazione è corretta perché, in base alle configurazioni di questo scenario, il traffico Internet deve essere inoltrato a Secure Access tramite VTI.

La fase 8 corrisponde alla fase di crittografia di una connessione VPN, in cui il traffico viene valutato e autorizzato per la crittografia, garantendo che i dati possano essere trasmessi in modo sicuro. La fase 9, d'altro canto, si concentra sulla gestione specifica del flusso del traffico all'interno del tunnel IPSec VPN, per verificare che il traffico crittografato sia correttamente indirizzato e autorizzato tramite il tunnel stabilito.

Per finalizzare, alla fine del risultato del flusso, è possibile visualizzare il traffico dal LAN al momento dell'PrimaryVTIinoltro del traffico ad Accesso sicuro. L'azione allow conferma che il traffico viene instradato senza problemi.

Informazioni correlate

- Supporto tecnico Cisco e download

- Cisco Secure Access Help Center

- Panoramica di Virtual Trusted Platform Module

- Zero Trust Access Module

- Errore Di Risoluzione Dei Problemi Relativi All'Accesso Sicuro: Il Servizio Di Registrazione Non Risponde. Contatta il tuo help desk IT"