Configuration d'un accès sécurisé avec pare-feu sécurisé haute disponibilité

Introduction

Ce document décrit comment configurer l'accès sécurisé avec le pare-feu sécurisé à haute disponibilité.

Conditions préalables

• Configurer le provisionnement utilisateur
• Configuration de l'authentification ZTNA SSO
• Configuration de l'accès sécurisé VPN à distance

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Firepower Management Center 7.2
• Défense contre les menaces Firepower 7.2
• Accès sécurisé
• Client sécurisé Cisco - VPN
• Client sécurisé Cisco - ZTNA
• ZTNA sans client

Composants utilisés

Les informations contenues dans ce document sont basées sur : 

• Firepower Management Center 7.2
• Défense contre les menaces Firepower 7.2
• Accès sécurisé
• Client sécurisé Cisco - VPN
• Client sécurisé Cisco - ZTNA

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.

Informations générales

Cisco a conçu Secure Access pour protéger et fournir un accès aux applications privées, sur site et dans le cloud. Il protège également la connexion du réseau à Internet. Pour ce faire, plusieurs méthodes et couches de sécurité sont mises en oeuvre, toutes visant à préserver les informations lorsqu'elles y accèdent via le cloud.

Diagramme du réseau

Configurer

Configurer le VPN sur un accès sécurisé

Accédez au panneau d'administration de Accès sécurisé.

• Cliquez sur Connect > Network Connections

• SousNetwork Tunnel Groupscliquez sur + Add

• ConfigurerTunnel Group Name, RegionetDevice Type
• Cliquer Next

• Configurez lesTunnel ID Formatet Passphrase
• CliquerNext

• Configurez les plages d'adresses IP ou les hôtes que vous avez configurés sur votre réseau et souhaitez faire passer le trafic par un accès sécurisé
• CliquerSave

Après avoir cliqué sur Save les informations sur le tunnel s'affiche, veuillez enregistrer ces informations pour l'étape suivante, Configure the tunnel on Secure Firewall.

Données pour la configuration du tunnel

Configurer le tunnel sur Secure Firewall

Configuration de l'interface du tunnel

Pour ce scénario, vous utilisez la configuration de l'interface de tunnel virtuel (VTI) sur le pare-feu sécurisé pour atteindre cet objectif ; n’oubliez pas que, dans ce cas, vous disposez d’un FAI double et que nous voulons disposer d’une haute disponibilité en cas de défaillance de l’un de vos FAI.

INTERFACES	RÔLE
WAN principal	WAN Internet principal
WAN secondaire	WAN Internet secondaire
VTI principal	Lié pour envoyer le trafic via l'Principal Internet WANaccès sécurisé
VTI secondaire	Lié pour envoyer le trafic via l'Secondary Internet WANaccès sécurisé

En fonction du scénario, nous avons PrimaryWAN et SecondaryWAN, que nous devons utiliser pour créer les interfaces VTI.

Accédez à votreFirepower Management Center > Devices.

• Choisissez votre FTD
• Choisir Interfaces

• Cliquez sur Add Interfaces > Virtual Tunnel Interface

• Configurez l’interface en fonction des informations suivantes

• Name : Configurez un nom qui fait référence à la PrimaryWAN interface
• Security Zone : Vous pouvez en réutiliser un autre Security Zone, mais en créer un nouveau pour le trafic d'accès sécurisé est préférable
• Tunnel ID : Ajouter un numéro pour l'ID de tunnel
• Tunnel Source : Choisissez votre PrimaryWAN interface et choisissez l'adresse IP privée ou publique de votre interface
• IPsec Tunnel Mode : Choisissez IPv4 et configurez une adresse IP non routable dans votre réseau avec le masque 30

Après cela, vous devez faire la même chose pour le SecondaryWAN interface, et vous avez tout configuré pour la haute disponibilité VTI, et par conséquent, vous avez le résultat suivant :

Dans ce scénario, les adresses IP utilisées sont les suivantes : 

Configuration IP VTI
Nom logique	IP	Plage
VTI principal	169.254.2.1/30	169.254.2.1-169.254.2.2
VTI secondaire	169.254.3.1/30	169.254.3.1-169.254.3.2

Configuration de la route statique pour l'interface secondaire

Pour permettre au trafic du SecondaryWAN interface d'atteindre leSecondary Datacenter IP Address, vous devez configurer une route statique vers l'adresse IP du centre de données. Vous pouvez le configurer avec une métrique de un (1) pour le placer au-dessus de la table de routage ; spécifiez également l'adresse IP en tant qu'hôte.

Naviguez jusqu'à Device > Device Management 

• Cliquez sur votre périphérique FTD
• Cliquez sur Routing
• Choisir Static Route > + Add Route

• Interface: Sélectionnez l'interface WAN secondaire
• Gateway: Sélectionnez la passerelle WAN secondaire
• Selected Network: Ajouter l'adresse IP du data center secondaire en tant qu'hôte ; vous pouvez trouver les informations sur les informations données quand vous configurez le tunnel sur l'étape d'accès sécurisé, Données pour la configuration du tunnel
• Metric: Utiliser un (1)
• OKCliquez sur Save et pour enregistrer les informations, puis procédez au déploiement.

Configurer le VPN pour un accès sécurisé en mode VTI

Pour configurer le VPN, accédez à votre pare-feu : 

• Cliquez sur Devices > Site to Site
• Cliquez sur + Site to Site VPN

Configuration des terminaux

Pour configurer l'étape Endpoints, vous devez utiliser les informations fournies sous l'étape, Data for Tunnel Setup.

• Nom de topologie : Créez un nom lié à l'intégration Secure Access
• Choisir Routed Based (VTI)
• Choisir Point to Point
• IKE Version: Choisir IKEv2

Sous la Node A, vous devez configurer les paramètres suivants :

• Device: Choisissez votre périphérique FTD
• Virtual Tunnel Interface: Sélectionnez la VTI associée à la PrimaryWAN Interface.
• Cochez la case correspondant à Send Local Identity to Peers
• Local Identity Configuration: Choisissez Email ID, et remplissez les informations en fonction des Primary Tunnel ID données fournies dans votre configuration à l'étape Data for Tunnel Setup

Après avoir configuré les informations sur le, PrimaryVTI cliquez sur + Add Backup VTI: 

• Virtual Tunnel Interface: Sélectionnez la VTI associée à la PrimaryWAN Interface.
• Cochez la case correspondant à Send Local Identity to Peers
• Local Identity Configuration: Choisissez Email ID, et remplissez les informations en fonction des Secondary Tunnel ID données fournies dans votre configuration à l'étape Data for Tunnel Setup

Sous la Node B, vous devez configurer les paramètres suivants :

• Device: Extranet
• Device Name: Choisissez un nom pour reconnaître l'accès sécurisé comme destination.
• Endpoint IP Address: La configuration pour le principal et le secondaire doit être Primaire Datacenter IP,Secondary Datacenter IP, vous pouvez trouver ces informations dans l'étape, Données pour la configuration du tunnel

Après cela, votre configuration pour Endpoints est terminée et vous pouvez maintenant passer à l'étape Configuration IKE.

Configuration IKE

Pour configurer les paramètres IKE, cliquez sur IKE.

Sous IKE, vous devez configurer les paramètres suivants :

• Policies: Vous pouvez utiliser la configuration Umbrella par défaut, Umbrella-AES-GCM-256 ou configurer un autre paramètre en fonction de la Supported IKEv2 and IPSEC Parameters

• Authentication Type: Clé manuelle pré-partagée
• Keyet:Confirm Key Vous pouvez trouver les Passphrase informations dans l'étape, Données pour la configuration du tunnel

Après cela, votre configuration pour IKE est terminée et vous pouvez maintenant passer à l'étape Configuration IPSEC.

Configuration IPSEC

Pour configurer les paramètres IPSEC, cliquez sur IPSEC.

Sous IPSEC, vous devez configurer les paramètres suivants :

• Policies: Vous pouvez utiliser la configuration Umbrella par défaut, Umbrella-AES-GCM-256 ou configurer un autre paramètre en fonction de la Supported IKEv2 and IPSEC Parameters

Après cela, votre configuration pour IPSEC est terminée et vous pouvez maintenant passer à l'étape Configuration avancée.

Configuration avancée

Pour configurer les paramètres avancés, cliquez sur Advanced (Avancé).

Sous Advanced, vous devez configurer les paramètres suivants :

• IKE Keepalive: Activer
• Threshold: 10
• Retry Interval: 2
• Identity Sent to Peers: AutoOuDN
• Peer Identity Validation: Ne pas vérifier

Après cela, vous pouvez cliquer surSaveet Deploy.

Après cela, votre configuration pour le VPN to Secure Access in VTI Mode est terminée et vous pouvez maintenant passer à l'étape, Configure Policy Base Routing.

Scénarios de configuration des politiques d'accès

Les règles de stratégie d'accès définies sont basées sur : 

Interface	Zone
VTI principal	SIG
VTI secondaire	SIG
LAN	LAN

Scénario d'accès Internet

Pour fournir l'accès à Internet à toutes les ressources que vous configurez sur le routage de base de stratégie, vous devez configurer certaines règles d'accès ainsi que certaines stratégies d'accès sécurisé. Permettez-moi donc d'expliquer comment y parvenir dans ce scénario : 

Cette règle permet d'accéder LAN à Internet et, dans ce cas, Internet est SIG.

Escenario RA-VPN

Pour fournir un accès à partir des utilisateurs RA-VPN, vous devez le configurer en fonction de la plage que vous avez attribuée sur le pool RA-VPN. 

Comment vérifiez-vous le pool d'adresses IP de votre VPNaaS ? 

Accédez à votre tableau de bord Secure Access

• Cliquez sur Connect > End User Connectivity
• Cliquez sur Virtual Private Network 
• Sous Manage IP Pools, cliquez sur Manage

• Vous voyez votre piscine en dessous Endpoint IP Pools

• Vous devez autoriser cette plage sous SIG, mais vous devez également l'ajouter sous la liste de contrôle d'accès que vous configurez dans votre PBR. 

Configuration des règles d'accès

Si vous ne configurez l'accès sécurisé que pour l'utiliser avec les capacités d'accès aux ressources d'applications privées, votre règle d'accès peut ressembler à ceci : 

Cette règle autorise le trafic du pool RA-VPN 192.168.50.0/24 vers votre LAN ; vous pouvez en spécifier davantage si nécessaire.

Configuration ACL

Pour autoriser le trafic de routage de SIG vers votre LAN, vous devez l'ajouter sous la liste de contrôle d'accès pour qu'il fonctionne sous le PBR.

Escenario ZTNA CLAP-BAP

Vous devez configurer votre réseau sur la base de la plage CGNAT 100.64.0.0/10 pour fournir un accès à votre réseau à partir des utilisateurs Client Base ZTA ou Browser Base ZTA.

Configuration des règles d'accès

Si vous ne configurez l'accès sécurisé que pour l'utiliser avec les capacités d'accès aux ressources d'applications privées, votre règle d'accès peut ressembler à ceci : 

Cette règle autorise le trafic de la plage ZTNA CGNAT 100.64.0.0/10 vers votre réseau local.

Configuration ACL

Pour autoriser le trafic de routage de SIG à votre LAN à l'aide de CGNAT, vous devez l'ajouter sous la liste de contrôle d'accès pour qu'il fonctionne sous le PBR.

Configurer le routage de base de stratégie

Pour fournir un accès aux ressources internes et à Internet via l'accès sécurisé, vous devez créer des routes via le routage PBR (Policy Base Routing) qui facilitent le routage du trafic de la source à la destination.

• Naviguez jusqu'à Devices > Device Management
• Choisissez le périphérique FTD où vous créez la route

• Cliquez sur Routing
• Choisir Policy Base Routing
• Cliquer Add

Dans ce scénario, vous sélectionnez toutes les interfaces que vous utilisez comme source pour acheminer le trafic vers l'accès sécurisé ou pour fournir une authentification utilisateur vers l'accès sécurisé à l'aide de RA-VPN ou d'un accès ZTA basé sur le client ou le navigateur aux ressources internes du réseau :

• Sous Ingress Interface, sélectionnez toutes les interfaces qui envoient le trafic via Secure Access :

• Sous Critères de correspondance et Interface de sortie, vous définissez les paramètres suivants après avoir cliqué surAdd:

• Match ACL: Pour cette liste de contrôle d'accès, vous configurez tout ce que vous routez vers l'accès sécurisé :

• Send To: Choisir une adresse IP
• IPv4 Addresses: Vous devez utiliser l'adresse IP suivante sous le masque 30 configuré sur les deux VTI ; vous pouvez vérifier que dans l'étape, VTI Interface Config

Interface	IP	GW
VTI principal	169.254.2.1/30	169.254.2.2
VTI secondaire	169.254.3.1/30	169.254.3.2

Après l'avoir configuré comme cela, vous obtenez le résultat suivant et vous pouvez continuer en cliquant sur Save:

Après cela, vous devez le Save reconfigurer, et vous l'avez configuré de la manière suivante : 

Après cela, vous pouvez déployer et vous voyez le trafic des machines configurées sur la liste de contrôle d'accès acheminer le trafic vers l'accès sécurisé :

À partir de la Conexion Events dans le FMC :

À partir de la Activity Search dans Accès sécurisé :

Configurer la stratégie d'accès Internet sur l'accès sécurisé

Pour configurer l'accès à Internet, vous devez créer la stratégie sur votre tableau de bord d'accès sécurisé :

• Cliquez sur Secure > Access Policy

• Cliquez sur Add Rule > Internet Access

Là, vous pouvez spécifier la source comme tunnel, et vers la destination, vous pouvez choisir n'importe lequel, en fonction de ce que vous voulez configurer sur la politique. Consultez le Guide de l'utilisateur Secure Access.

Configuration de l'accès aux ressources privées pour ZTNA et RA-VPN

Pour configurer l'accès pour les ressources privées, vous devez d'abord créer les ressources sous le tableau de bord d'accès sécurisé :

Cliquez sur Resources > Private Resources

• Cliquez ensuite sur ADD 

Sous la configuration, vous trouverez les sections suivantes à configurer : General, Communication with Secure Access Cloud and Endpoint Connection Methods.

Généralités

• Private Resource Name : Créez un nom pour la ressource à laquelle vous accordez un accès sécurisé à votre réseau

Méthodes de connexion Endpoint 

• Zero Trust Connections: Cochez la case.
• Client-based connection: Si vous l'activez, vous pouvez utiliser le module Secure Client - Zero Trust pour activer l'accès via le mode client-base.
• Remote Reachable Address (FQDN, Wildcard FQDN, IP Address) : Configurez les ressources IP ou FQDN ; si vous configurez le nom de domaine complet, vous devez ajouter le DNS pour résoudre le nom.
• Browser-based connection: si vous l'activez, vous pouvez accéder à vos ressources via un navigateur (veuillez ajouter uniquement des ressources avec une communication HTTP ou HTTPS)
• Public URL for this resource: Configurez l'URL publique que vous utilisez via le navigateur ; Secure Access protège cette ressource.
• Protocol: Sélectionnez le protocole (HTTP ou HTTPS)

VPN Connection: Cochez cette case pour activer l'accès via RA-VPNaaS.

Après cela, cliquez sur Save et vous pourrez ajouter cette ressource à la Access Policy.

Configurer la stratégie d'accès 

Lorsque vous créez la ressource, vous devez l'affecter à l'une des stratégies d'accès sécurisé :

• Cliquez sur Secure > Access Policy

• Cliquer Add > Private Resource

Pour cette règle d'accès privé, vous configurez les valeurs par défaut pour fournir l'accès à la ressource. Pour en savoir plus sur les configurations des stratégies, consultez le Guide de l'utilisateur.

• Action : Sélectionnez Autoriser pour fournir l'accès à la ressource.
• From : Spécifiez l'utilisateur qui peut être utilisé pour se connecter à la ressource.
• To : Sélectionnez la ressource à laquelle vous souhaitez accéder via l'accès sécurisé.

• Zero-Trust Client-based Posture Profile: Choisir le profil par défaut pour l'accès client de base
• Zero-Trust Browser-based Posture Profile: sélectionnez l'accès de base par défaut du navigateur de profils

Après cela, cliquez sur Next etSave et votre configuration, et vous pouvez essayer d'accéder à vos ressources via RA-VPN et Client Base ZTNA ou Browser Base ZTNA.

Dépannage

Pour effectuer un dépannage en fonction de la communication entre le pare-feu sécurisé et l'accès sécurisé, vous pouvez vérifier si Phase1 (IKEv2) et Phase2 (IPSEC) sont établies entre les périphériques sans problème.

Vérification de Phase 1 (IKEv2)

Pour vérifier Phase1, vous devez exécuter la commande suivante sur l'interface de ligne de commande de votre FTD :

show crypto isakmp sa

Dans ce cas, le résultat souhaité est deux IKEv2 SAs adresses IP de centre de données d'accès sécurisé et l'état souhaité est 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

Vérification de Phase2 (IPSEC)

Pour vérifier Phase2, vous devez exécuter la commande suivante sur l'interface de ligne de commande de votre 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

Dans la dernière sortie, vous pouvez voir les deux tunnels établis ; ce qui n'est pas souhaité, c'est la sortie suivante sous le paquetencapsetdecaps.

Si vous avez ce scénario, ouvrez un dossier auprès du TAC.

Fonction de haute disponibilité

La fonction des tunnels avec accès sécurisé communiquant avec le data center dans le cloud est active/passive, ce qui signifie que seule la porte pour DC 1 sera ouverte pour recevoir le trafic ; la porte du DC 2 est fermée jusqu'à ce que le tunnel numéro 1 tombe en panne. 

Vérification du routage du trafic pour un accès sécurisé

Dans cet exemple, nous utilisons la source comme machine sur le réseau du pare-feu :

• Source : 192.168.10.40
• Destination : 146.112.255.40 (IP de surveillance d'accès sécurisé)

Exemple : 

commande : 

 packet-tracer input LAN tcp 192.168.10.40 3422 146.112.255.40 80

Sortie :

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

Ici, beaucoup de choses peuvent nous donner un contexte sur la communication et savoir si tout est correctement sous la configuration PBR pour acheminer correctement le trafic vers l'accès sécurisé : 

La phase 2 indique que le trafic est transféré vers l'PrimaryVTIinterface, ce qui est correct car, en fonction des configurations de ce scénario, le trafic Internet doit être transféré vers l'accès sécurisé via l'interface VTI.

La phase 8 correspond à l'étape de cryptage dans une connexion VPN, où le trafic est évalué et autorisé pour le cryptage, garantissant que les données peuvent être transmises en toute sécurité. La phase 9, quant à elle, se concentre sur la gestion spécifique du flux de trafic dans le tunnel IPSec VPN, confirmant que le trafic chiffré est correctement routé et autorisé à passer par le tunnel établi.

Pour finaliser, à la fin du résultat du flux, vous pouvez voir le trafic de la LAN à l'PrimaryVTIacheminement du trafic vers l'accès sécurisé. L'action allow confirme que le trafic est routé sans problème.

Informations connexes

• Assistance technique de Cisco et téléchargements
• Centre d'aide Cisco Secure Access
• Présentation du module de plateforme sécurisée virtuelle
• Module d'accès Zero Trust
• Dépannez L'Erreur D'Accès Sécurisé « Le Service D'Inscription Ne Répond Pas. Contactez votre service d'assistance informatique"