Configure Secure Access with Secure Firewall with High Availability

Introduction

This document describes how to configure Secure Access with Secure Firewall with High Availability.

Prerequisites

• Configure User Provisioning
• ZTNA SSO Authentication Configuration
• Configure Remote Access VPN Secure Access

Requirements

Cisco recommends that you have knowledge of these topics:

• Firepower Management Center 7.2
• Firepower Threat Defence 7.2
• Secure Access
• Cisco Secure Client - VPN
• Cisco Secure Client - ZTNA
• Clientless ZTNA

Components Used

The information in this document is based on: 

• Firepower Management Center 7.2
• Firepower Threat Defence 7.2
• Secure Access
• Cisco Secure Client - VPN
• Cisco Secure Client - 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. If your network is live, ensure that you understand the potential impact of any command.

Background Information

Cisco has designed Secure Access to protect and provide access to private applications, both on-premise and cloud-based. It also safeguards the connection from the network to the internet. This is achieved through the implementation of multiple security methods and layers, all aimed at preserving the information as they access it via the cloud.

Network Diagram

Configure

Configure the VPN on Secure Access

Navigate to the admin panel of Secure Access.

• Click on Connect > Network Connections

• Under Network Tunnel Groups click on + Add

• Configure Tunnel Group Name, Region andDevice Type
• Click Next

• Configure the Tunnel ID Format and Passphrase
• ClickNext

• Configure the IP address ranges or hosts that you have configured on your network and want to pass the traffic through Secure Access
• ClickSave

After you click on Save the information about the tunnel gets displayed, please save that information for the next step, Configure the tunnel on Secure Firewall.

Data for Tunnel Setup

Configure the tunnel on Secure Firewall

Configure the Tunnel Interface

For this scenario, you use Virtual Tunnel Interface (VTI) configuration on Secure Firewall to achieve this goal; remember, in this case, you have double ISP, and we want to have HA if one of your ISPs fails.

Note: 1. You need to add or assign a static route to the Primary or Secondary Datacenter IP to be able to have both tunnels up.

Note: 2. If you have ECMP configured between the interfaces, you do not need to create any static route to the Primary or Secondary Datacenter IP to be able to have both tunnels up.

Based on the scenario, we have PrimaryWAN and SecondaryWAN, which we must use to create the VTI interfaces.

Navigate to your Firepower Management Center > Devices.

• Choose your FTD
• Choose Interfaces

• Click on Add Interfaces > Virtual Tunnel Interface

• Configure the interface based on the next information

• Name : Configure a name that refers to the PrimaryWAN interface
• Security Zone : You can reuse another Security Zone, but creating a new one for Secure Access traffic is better
• Tunnel ID : Add a number for the Tunnel ID
• Tunnel Source : Choose your PrimaryWAN interface and choose the private or public IP of your interface
• IPsec Tunnel Mode : Choose IPv4 and configure a non-routable IP in your network with mask 30

Note: For the VTI interface, you must use a non-routable IP; for example, if you have two VTI interfaces, you can use 169.254.2.1/30 for the PrimaryVTI and 169.254.3.1/30 for the SecondaryVTI.

After that, you need to do the same for the SecondaryWAN interface, and you have everything set up for the VTI High Availability, and as a result, you have the next result:

For this scenario, the IPs used are: 

Configure Static Route for the Secondary Interface

To permit the traffic of the SecondaryWAN interface to reach the Secondary Datacenter IP Address you need to configure a static route to the datacenter IP. You can configure it with a metric of one (1) to make it on top of the routing table; also, specify the IP as a host.

Caution: This is only needed if you do not have an ECMP setup between the WAN channels; if you have ECMP configured, you can jump to the next step.

Navigate to Device > Device Management 

• Click on your FTD device
• Click on Routing
• Choose Static Route > + Add Route

• Interface: Choose the SecondaryWAN Interface
• Gateway: Choose the SecondaryWAN Gateway
• Selected Network: Add the Secondary Datacenter IP as a host; you can find the information on the information given when you configure the tunnel on Secure Access step, Data for Tunnel Setup
• Metric: Use one (1)
• ClickOKand Save to save the information, then deploy.

Configure the VPN to Secure Access in VTI Mode

To configure the VPN, navigate to your firewall: 

• Click on Devices > Site to Site
• Click on + Site to Site VPN

Endpoints Configuration

To configure the Endpoints step, you need to use the information provided under the step, Data for Tunnel Setup.

• Topology Name: Create a name related to the Secure Access integration
• Choose Routed Based (VTI)
• Choose Point to Point
• IKE Version: Choose IKEv2

Note: IKEv1 is not supported for integration with Secure Access.

Under the Node A, you need to configure the next parameters:

• Device: Choose your FTD device
• Virtual Tunnel Interface: Choose the VTI related to the PrimaryWAN Interface.
• Mark the checkbox for Send Local Identity to Peers
• Local Identity Configuration: Choose Email ID, and fill in the information based on the Primary Tunnel ID provided in your configuration on the step, Data for Tunnel Setup

After you configure the information on the PrimaryVTI click on + Add Backup VTI: 

• Virtual Tunnel Interface: Choose the VTI related to the PrimaryWAN Interface.
• Mark the checkbox for Send Local Identity to Peers
• Local Identity Configuration: Choose Email ID, and fill in the information based on the Secondary Tunnel ID provided in your configuration on the step, Data for Tunnel Setup

Under the Node B, you need to configure the next parameters:

• Device: Extranet
• Device Name: Choose a Name to recognize Secure Access as the destination.
• Endpoint IP Address: The configuration for primary and secondary must be Primary Datacenter IP,Secondary Datacenter IP, you can find that information in the step, Data for Tunnel Setup

After that, your configuration for Endpoints is completed, and you can now go to the step, IKE Configuration.

IKE Configuration

To configure the IKE parameters, click on IKE.

Under IKE, you need to configure the next parameters:

• Policies: You can use the default Umbrella configuration Umbrella-AES-GCM-256 or you can configure a different parameters based on the Supported IKEv2 and IPSEC Parameters

• Authentication Type: Pre-shared Manual Key
• Keyand Confirm Key: You can find the Passphrase information in the step, Data for Tunnel Setup

After that, your configuration for IKE is completed, and you can now go to the step, IPSEC Configuration.

IPSEC Configuration

To configure the IPSEC parameters, click on IPSEC.

Under IPSEC, you need to configure the next parameters:

• Policies: You can use the default Umbrella configuration Umbrella-AES-GCM-256 or you can configure a different parameters based on the Supported IKEv2 and IPSEC Parameters

Note: Nothing else is required on IPSEC.

After that, your configuration for IPSEC is completed, and you can now go to the step, Advanced Configuration.

Advanced Configuration

To configure the advanced parameters, click on Advanced.

Under Advanced, you need to configure the next parameters:

• IKE Keepalive: Enable
• Threshold: 10
• Retry Interval: 2
• Identity Sent to Peers: autoOrDN
• Peer Identity Validation: Do not Check

After that, you can click on Save and Deploy.

Note: After a few minutes, you see the VPN established for both nodes.

After that, your configuration for the VPN to Secure Access in VTI Mode is completed, and you can now go to the step, Configure Policy Base Routing.

Warning: Traffic to Secure Access is forwarded only to the primary Tunnel when both tunnels are established; if the primary gets down, Secure Access allow the traffic to be forwarded through the secondary Tunnel.

Note: The failover on the Secure Access site is based on the DPD values documented on the user guide for Supported IPsec values.

Access Policy Configuration Scenarios

The access policy rules defined are based on: 

Internet Access Scenario

To provide access to the internet to all the resources that you configure on the Policy Base Routing, you need to configure some access rules and also some policies in secure access, so let me explain how to achieve that in this scenario: 

This rule provide access to the LAN to the Internet, and in this case, the Internet is SIG.

RA-VPN Escenario

To provide access from the RA-VPN users, you need to configure it based on the range you assigned on the RA-VPN Pool. 

Note: To configure your RA-VPNaaS policy, you can go through Manage Virtual Private Networks

How do you verify the IP pool of your VPNaaS? 

Navigate to your Secure Access Dashboard

• Click on Connect > End User Connectivity
• Click on Virtual Private Network 
• Under Manage IP Pools, click on Manage

• You see your pool under Endpoint IP Pools

• You need to permit this range under SIG, but you must also add it under the ACL that you configure in your PBR. 

Access Rule Configuration

If you are only configuring Secure Access to use it with the capabilities to access the private applications resources, your access rule can look like this: 

That rule permits traffic from the RA-VPN Pool 192.168.50.0/24 to your LAN; you can specify more if needed.

ACL Configuration

To permit the routing traffic from SIG to your LAN, you must add it under the ACL to make it work under the PBR.

CLAP-BAP ZTNA Escenario

You must configure your network based on the CGNAT range 100.64.0.0/10 to provide access to your network from the Client Base ZTA or Browser Base ZTA users.

Access Rule Configuration

If you are only configuring Secure Access to use it with the capabilities to access the private applications resources, your access rule can look like this: 

That rule permits traffic from the ZTNA CGNAT Range 100.64.0.0/10 to your LAN.

ACL Configuration

To permit the routing traffic from SIG using CGNAT to your LAN, you must add it under the ACL to make it work under the PBR.

Configure Policy Base Routing

To provide access to internal resources and the Internet through Secure Access, you must create routes via Policy Base Routing (PBR) that facilitate routing the traffic from the source to the destination.

• Navigate to Devices > Device Management
• Choose the FTD device where you create the route

• Click on Routing
• Choose Policy Base Routing
• Click Add

In this scenario, you select all the interfaces you use as a source to route traffic to Secure Access or to provide user authentication to Secure Access using RA-VPN or client-based or browser-based ZTA access to the Network internal resources:

• Under Ingress Interface, select all the interfaces that send traffic through Secure Access:

• Under Match Criteria and Egress Interface, you define the next parameters after you click on Add:

• Match ACL: For this ACL, you configure everything that you route to Secure Access:

• Send To: Choose IP Address
• IPv4 Addresses: You must use the next IP under the mask 30 configured on both VTI; you can check that under the step, VTI Interface Config

After you configure it like that, you have the next result, and you can proceed to click Save:

After that, you need to Save it again, and you have it configured in the next way: 

After that, you can Deploy, and you see the traffic of the machines configured on the ACL routing the traffic to Secure Acces:

From the Conexion Events in the FMC:

From the Activity Search in Secure Access:

Note: By default, the default Secure Access Policy allows traffic to the internet. To provide access to private applications, you need to create private resources and add them to the access policy for private resource access.

Configure Internet Access Policy on Secure Access

To configure the access for internet access, you need to create the policy on your Secure Access Dashboard:

• Click on Secure > Access Policy

• Click on Add Rule > Internet Access

There, you can specify the source as the tunnel, and to the destination, you can choose any, depending on what you want to configure on the policy. Please check the Secure Access User Guide.

Configure Private Resource Access for ZTNA and RA-VPN

To configure the access for private resources, you need to create the resources first under the Secure Access Dashboard:

Click on Resources > Private Resources

• Then click ADD 

Under the configuration, you find the next sections to configure: General, Communication with Secure Access Cloud and Endpoint Connection Methods.

General

• Private Resource Name : Create a name for the resource you provide access through Secure Access to your network

Endpoint Connection Methods 

• Zero Trust Connections: Mark the checkbox.
• Client-based connection: If you enable it, you can use the Secure Client - Zero Trust Module to enable access through client-base mode.
• Remote Reachable Address (FQDN, Wildcard FQDN, IP Address) : Configure the resources IP or FQDN; if you configure FQDN, you need to add the DNS to resolve the name.
• Browser-based connection: If you enable it, you can access your resources via browser (Please only add resources with HTTP or HTTPS communication)
• Public URL for this resource: Configure the public URL you use through the browser; Secure Access protects this resource.
• Protocol: Select the protocol (HTTP or HTTPS)

VPN Connection: Mark the checkbox to enable access via RA-VPNaaS.

After that, click Save and you are able to add that resource to the Access Policy.

Configure the Access Policy 

When you create the resource, you need to assign it to one of the secure access policies:

• Click on Secure > Access Policy

• Click Add > Private Resource

For this Private Access rule, you configure the default values to provide access to the resource. To know more about policy configurations, check the User Guide.

• Action : Choose Allow to provide access to the resource.
• From : Specify the user that can be used to log in to the resource.
• To : Choose the resource that you want to access through Secure Access.

• Zero-Trust Client-based Posture Profile: Choose the default profile for client base access
• Zero-Trust Browser-based Posture Profile: Choose the default profile browser base access

Note: To learn more about the posture policy, please check the user guide for Secure Access.

After that, click Next and Save and your configuration, and you can try to access your resources through RA-VPN and Client Base ZTNA or Browser Base ZTNA.

Troubleshoot

To troubleshoot based on the communication between Secure Firewall and Secure Access, you can be able to verify if Phase1 (IKEv2) and phase2 (IPSEC) are established between the devices without a problem.

Verify Phase1 (IKEv2)

To verify Phase1 you need to run the next command on the CLI of your FTD:

show crypto isakmp sa

In this case, the desired output is two IKEv2 SAs established to the Datacenter IPs of Secure Access and the desired status as 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

Verify Phase2 (IPSEC)

To verify Phase2, you need to run the next command on the CLI of your 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

In the last output, you can see both tunnels established; what is not desired is the next output under the packet encaps and decaps.

If you have this scenario, open a case with TAC.

High Availability Function

The function of the tunnels with Secure Access communicating with the datacenter in the cloud Is active/passive, which means only the door for DC 1 will be open to receive traffic; the DC 2 door is closed until tunnel number 1 gets down. 

Verify Traffic Routing to Secure Access

In this example, we use the source as the machine on the firewall network:

• Source: 192.168.10.40
• Destination: 146.112.255.40 (Secure Access Monitoring IP)

Example: 

Command: 

 packet-tracer input LAN tcp 192.168.10.40 3422 146.112.255.40 80

Output:

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

Here, many things can give us context about the communication and know if everything is correctly under the PBR configuration to route the traffic correctly to Secure Access: 

Phase 2 indicates that the traffic is being forwarded to the PrimaryVTI interface, which is correct because, based on the configurations in this scenario, the internet traffic must be forwarded to Secure Access through the VTI.

Phase 8 corresponds to the encryption stage in a VPN connection, where traffic is evaluated and authorized for encryption, ensuring that data can be securely transmitted. Phase 9, on the other hand, focuses on the specific management of traffic flow within the VPN IPSec tunnel, confirming that encrypted traffic is properly routed and allowed through the established tunnel.

To finalize, at the end of the flow result, you can see the traffic from the LAN to PrimaryVTI forwarding the traffic to Secure Access. The action allow confirms that the traffic is routed without problem.

Related Information

• Cisco Technical Support & Downloads
• Cisco Secure Access Help Center
• Virtual Trusted Platform Module Overview
• Zero Trust Access Module
• Troubleshoot Secure Access Error "Enrollment Service Is Not Responding. Contact Your IT Help Desk"