Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Configurar

Diagrama de la red

Configuración de fuga de ruta

Configuración de ZBFW

Verificación

Troubleshoot

Método 1. Para encontrar la VPN de destino de la tabla OMP

Método 2. Para encontrar la VPN de destino con la ayuda de los comandos de plataforma

Método 3. Para encontrar la VPN de destino con la ayuda de la herramienta de seguimiento de paquetes

Posibles problemas debido a la conmutación por fallas

Introducción

Este documento describe cómo configurar, verificar y solucionar problemas de firewall basado en zonas (ZBFW) con filtrado de rutas entre redes privadas virtuales (VPN).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- La superposición de la SD-WAN de Cisco genera una configuración inicial

- Configuración de ZBFW desde la interfaz de usuario (IU) de vManage

- Configuración de la política de control de fuga de ruta desde la IU de vManage

Componentes Utilizados

Para los fines de la demostración, se utilizaron estos programas:

- Controlador Cisco SD-WAN vSmart con versión 20.6.2 del software

- Controlador Cisco SD-WAN vManage con versión de software 20.6.2

- Dos routers de plataforma de extremo virtual Cisco IOS®-XE Catalyst 8000V con versión de software 17.6.2 que se ejecutan en modo de controlador

- Tres routers de plataforma de borde virtual Cisco IOS-XE Catalyst 8000V con versión de software 17.6.2 que se ejecutan en modo autónomo

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Este documento explica cómo el router determina la asignación de VPN de destino en la superposición SD-WAN y cómo verificar y resolver problemas de fuga de rutas entre las VPN. También describe las peculiaridades de la selección de trayectoria en caso de que la misma subred se anuncie desde una VPN diferente y qué tipo de problemas pueden surgir debido a esto.

Configurar

Diagrama de la red

Ambos routers SD-WAN se configuraron con parámetros básicos para establecer conexiones de control con controladores SD-WAN y conexiones de plano de datos entre ellos. Los detalles de esta configuración están fuera del alcance para el propósito de este documento. En la tabla siguiente se resumen las asignaciones de VPN, ID de sitio y zonas.

cE1

cE2

ID del sitio

11

12

VPN

30

10,20

IP del sistema

169.254.206.11

169.254.206.12

Los routers en el lado del servicio se configuraron con rutas predeterminadas estáticas en cada Virtual Routing and Forwarding (VRF) que apunta al router SD-WAN que corresponde. De manera similar, los routers periféricos SD-WAN se configuraron con rutas estáticas que apuntan a las subredes que corresponden. Tenga en cuenta que, para demostrar los posibles problemas de fuga de ruta y ZBFW, los routers detrás del lado de servicio de cE2 tienen la misma subred 192.168.12.0/24. En ambos routers detrás de cE2, hay una interfaz de loopback configurada para emular un host con la misma dirección IP 192.168.12.12.

Es importante tener en cuenta que los routers Cisco IOS-XE R10, R20 y R30 se ejecutan en modo autónomo en los lados de servicio de las rutas periféricas SD-WAN que sirven principalmente para emular los hosts finales en esta demostración. Las interfaces de loopback en las rutas periféricas SD-WAN no se pueden utilizar para este fin en lugar de hosts reales como routers de servicio, porque el tráfico que se origina desde una interfaz en un VRF de un router periférico SD-WAN no se considera tráfico originado en la zona ZBFW que corresponde, y más bien pertenece a la zona autónoma especial de un router periférico. Es por eso que la zona ZBFW no se puede considerar igual que VRF. Una discusión detallada de la zona de uno mismo está fuera del alcance de este artículo.

Configuración de fuga de ruta

El objetivo principal de configuración de la política de control es permitir la fuga de ruta de todas las rutas de VPN 10 y 20 a VPN 30. VRF 30 existe solamente en el router cE1 y los VRF 10 y 20 se configuran solamente en el router cE2. Para lograr esto, se configuraron dos políticas de topología (control personalizado). Esta es la topología para exportar todas las rutas de VPN 10 y 20 a VPN 30.

Tenga en cuenta que la Acción predeterminada está establecida en Permitir, para evitar el bloqueo de anuncios de TLOC o de anuncios de rutas normales dentro de VPN accidentalmente.

De manera similar, la política de topología se configuró para permitir el anuncio inverso de la información de ruteo de VPN 30 a VPN 10 y 20.

A continuación, ambas directivas de topología se asignan a las listas de sitios correspondientes, en la dirección de entrada (entrante). El controlador vSmart exporta las rutas de VPN 30 a las tablas de protocolo de administración de superposición (OMP) de VPN 10 y 20 cuando se reciben desde cE1 (id. de sitio 11).

De forma similar, vSmart exporta las rutas de VPN 10 y 20 a la tabla de routing VPN 30 al recibir las rutas VPN 10 y 20 desde cE2 (id. de sitio 12).

Aquí también hay una vista previa completa de la configuración de la política de control para referencia.

viptela-policy:policy

control-policy LEAK_VPN10_20_to_30

sequence 1

match route

vpn-list VPN_10_20

prefix-list _AnyIpv4PrefixList

!

action accept

export-to vpn-list VPN_30

!

!

default-action accept

!

control-policy LEAK_VPN30_to_10_20

sequence 1

match route

vpn-list VPN_30

prefix-list _AnyIpv4PrefixList

!

action accept

export-to vpn-list VPN_10_20

!

!

default-action accept

!

lists

site-list SITE_11

site-id 11

!

site-list SITE_12

site-id 12

!

vpn-list VPN_10_20

vpn 10

vpn 20

!

vpn-list VPN_30

vpn 30

!

prefix-list _AnyIpv4PrefixList

ip-prefix 0.0.0.0/0 le 32

!

!

!

apply-policy

site-list SITE_12

control-policy LEAK_VPN10_20_to_30 in

!

site-list SITE_11

control-policy LEAK_VPN30_to_10_20 in

!

!

La política debe activarse desde la sección Configuración > Políticas del controlador vManage para que sea efectiva en el controlador vSmart.

Configuración de ZBFW

Aquí hay una tabla que resume ZBFW para filtrar los requisitos a efectos de demostración en este artículo.

Zona de destino

VPN_10

VPN_20

VPN_30

Zona de origen

VPN_10

permitir dentro de la zona

Denegar

Denegar

VPN_20

Denegar

permitir dentro de la zona

Permiso

VPN_30

Permiso

Denegar

permitir dentro de la zona

El objetivo principal es permitir cualquier tráfico ICMP (Internet Control Message Protocol) que se haya originado desde el lado de servicio del router cE1 VPN 30 y esté destinado a VPN 10 pero no a VPN 20. El tráfico de retorno se debe permitir automáticamente.

También se debe permitir que cualquier tráfico ICMP del router cE2 service-side VPN 20 pase al lado de servicio VPN 30 de cE1, pero no al lado de VPN 10. El tráfico de retorno de VPN 30 a VPN 20 se debe permitir automáticamente.

Aquí puede encontrar la vista previa de la política de ZBFW como referencia.

policy

zone-based-policy VPN_20_to_30

sequence 1

seq-name Rule_1

match

source-ip 192.168.20.0/24

destination-ip 192.168.30.0/24

protocol 1

!

action inspect

!

!

sequence 11

seq-name Rule_2

match

source-ip 192.168.12.0/24

destination-ip 192.168.30.0/24

protocol 1

!

action inspect

!

!

default-action drop

!

zone-based-policy VPN_30_to_10

sequence 1

seq-name Rule_1

match

source-ip 192.168.30.0/24

destination-ip 192.168.10.0/24

protocol 1

!

action inspect

!

!

sequence 11

seq-name Rule_2

match

protocol 1

source-ip 192.168.30.0/24

destination-ip 192.168.12.0/24

!

action inspect

!

!

default-action drop

!

zone VPN_10

vpn 10

!

zone VPN_20

vpn 20

!

zone VPN_30

vpn 30

!

zone-pair ZP_VPN_20_VPN_30_VPN_20_to_30

source-zone VPN_20

destination-zone VPN_30

zone-policy VPN_20_to_30

!

zone-pair ZP_VPN_30_VPN_10_VPN_30_to_10

source-zone VPN_30

destination-zone VPN_10

zone-policy VPN_30_to_10

!

zone-to-nozone-internet deny

!

Para aplicar la política de seguridad, se debe asignar en la sección de menú desplegable Política de seguridad de la sección Plantillas adicionales de la plantilla de dispositivo.

Una vez actualizada la plantilla de dispositivos, la directiva de seguridad se activa en el dispositivo en el que se aplicó la directiva de seguridad. A efectos de demostración en este documento, fue suficiente con habilitar la política de seguridad sólo en el router cE1.

Verificación

Ahora debe comprobar que se han alcanzado los objetivos de la política de seguridad (ZBFW) necesaria.

La prueba con ping confirma que el tráfico de la zona VPN 10 a VPN 30 se niega como se esperaba porque no hay ningún par de zonas configurado para el tráfico de VPN 10 a VPN 30.

R10#ping 192.168.30.30 source 192.168.10.10

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.30.30, timeout is 2 seconds:

Packet sent with a source address of 192.168.10.10

.....

Success rate is 0 percent (0/5)

R10#ping 192.168.30.30 source 192.168.12.12

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.30.30, timeout is 2 seconds:

Packet sent with a source address of 192.168.12.12

.....

Success rate is 0 percent (0/5)

De manera similar, se permite el tráfico de VPN 20 a VPN 30 según lo esperado por la configuración de la política de seguridad.

R20#ping 192.168.30.30 source 192.168.20.20

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.30.30, timeout is 2 seconds:

Packet sent with a source address of 192.168.20.20

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

R20#ping 192.168.30.30 source 192.168.12.12

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.30.30, timeout is 2 seconds:

Packet sent with a source address of 192.168.12.12

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

El tráfico de VPN 30 a la subred 192.168.10.0/24 en la zona VPN 10 está permitido según lo esperado por la configuración de políticas.

R30#ping 192.168.10.10 source 192.168.30.30

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.10.10, timeout is 2 seconds:

Packet sent with a source address of 192.168.30.30

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Se ha denegado el tráfico de VPN 30 a la subred 192.168.20.0/24 en la zona VPN 20 porque no hay ningún par de zonas configurado para este tráfico, lo que se espera.

R30#ping 192.168.20.20 source 192.168.30.30

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.20.20, timeout is 2 seconds:

Packet sent with a source address of 192.168.30.30

.....

Success rate is 0 percent (0/5)

Se pueden observar resultados adicionales que pueden interesarle cuando intenta hacer ping a la dirección IP 192.168.12.12 porque puede estar en la zona VPN 10 o VPN 20, y es imposible determinar la VPN de destino desde la perspectiva del router R30 situado en el lado de servicio del router periférico SD-WAN cE1.

R30#ping 192.168.12.12 source 192.168.30.30

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.12.12, timeout is 2 seconds:

Packet sent with a source address of 192.168.30.30

.....

Success rate is 0 percent (0/5)

El resultado es el mismo para todos los orígenes en VRF 30. Esto confirma que no depende de los resultados de la función hash de múltiples rutas de igual coste (ECMP):

R30#ping 192.168.12.12 source 192.168.30.31

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.12.12, timeout is 2 seconds:

Packet sent with a source address of 192.168.30.31

.....

Success rate is 0 percent (0/5)

R30#ping 192.168.12.12 source 192.168.30.32

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.12.12, timeout is 2 seconds:

Packet sent with a source address of 192.168.30.32

.....

Success rate is 0 percent (0/5)

Según los resultados de la prueba para la IP de destino 192.168.12.12, solo puede adivinar que se encuentra en VPN 20 porque no responde a las solicitudes de eco ICMP y es más probable que se bloquee porque no hay ningún par de zonas configurado para permitir el tráfico de VPN 30 a VPN 20 (como se desee). Si un destino con la misma dirección IP 192.168.12.12 se encuentra en VPN 10 y se supone que responde a la solicitud de eco ICMP, según la política de seguridad de ZBFW para el tráfico ICMP de VPN 30 a VPN 20, se debe permitir el tráfico. Debe confirmar la VPN de destino.

Troubleshoot

Método 1. Para encontrar la VPN de destino de la tabla OMP

Una simple verificación de la tabla de ruteo en cE1 no ayuda a entender la VPN de destino real. La información más útil que puede obtener de la salida es una IP del sistema del destino (169.254.206.12) y también que no hay ECMP que ocurra.

cE1# show ip route vrf 30 192.168.12.0 255.255.255.0

Routing Table: 30

Routing entry for 192.168.12.0/24

Known via "omp", distance 251, metric 0, type omp

Last update from 169.254.206.12 on Sdwan-system-intf, 01:34:24 ago

Routing Descriptor Blocks:

* 169.254.206.12 (default), from 169.254.206.12, 01:34:24 ago, via Sdwan-system-intf

Route metric is 0, traffic share count is 1

Para averiguar la VPN de destino, primero, es necesario averiguar la etiqueta de servicio de la tabla OMP en cE1 para el prefijo de interés.

cE1#show sdwan omp routes vpn 30 192.168.12.0/24

Generating output, this might take time, please wait ...

Code:

C   -> chosen

I   -> installed

Red -> redistributed

Rej -> rejected

L   -> looped

R   -> resolved

S   -> stale

Ext -> extranet

Inv -> invalid

Stg -> staged

IA  -> On-demand inactive

U   -> TLOC unresolved

PATH                      ATTRIBUTE

FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE

-----------------------------------------------------------------------------------------------------------

169.254.206.4    12     1007     C,I,R     installed  169.254.206.12   private2         ipsec  -

Podemos ver que el valor de la etiqueta es 1007. Finalmente, se puede encontrar la VPN de destino si todos los servicios que se originan en el router que posee el sistema IP 169.254.206.12 se verifican en el controlador vSmart.

vsmart1# show omp services family ipv4 service VPN originator 169.254.206.12

C   -> chosen

I   -> installed

Red -> redistributed

Rej -> rejected

L   -> looped

R   -> resolved

S   -> stale

Ext -> extranet

Inv -> invalid

Stg -> staged

IA  -> On-demand inactive

U   -> TLOC unresolved

PATH

VPN    SERVICE  ORIGINATOR      FROM PEER        ID     LABEL    STATUS

---------------------------------------------------------------------------

1      VPN      169.254.206.12  169.254.206.12   82     1003     C,I,R

2      VPN      169.254.206.12  169.254.206.12   82     1004     C,I,R

10     VPN      169.254.206.12  169.254.206.12   82     1006     C,I,R

17     VPN      169.254.206.12  169.254.206.12   82     1005     C,I,R

20     VPN      169.254.206.12  169.254.206.12   82     1007     C,I,R

Según la etiqueta VPN 1007, se puede confirmar que la VPN de destino es 20.

Método 2. Para encontrar la VPN de destino con la ayuda de los comandos de plataforma

Para averiguar la VPN de destino con la ayuda de los comandos de plataforma, primero debe obtener un ID de VRF interno para VPN 30 en el router cE1 con la ayuda de los comandos show ip vrf detail 30 o show platform software ip f0 cef table * summary.

cE1#show ip vrf detail 30 | i Id

VRF 30 (VRF Id = 1); default RD 1:30; default VPNID

cE1#show platform software ip f0 cef table * summary | i VRF|^30

Name             VRF id  Table id    Protocol         Prefixes    State

30               1       1           IPv4             21          hw: 0x561b60f07a50 (created)

En este caso, el VRF ID 1 se asignó al VRF denominado 30. Los comandos de la plataforma revelan la cadena de objetos Output Chain Element (OCE) en el software SD-WAN que representa la lógica de reenvío interna que determina la trayectoria del paquete en el software Cisco IOS-XE:

cE1#show platform software ip F0 cef table index 1 prefix 192.168.12.0/24 oce

=== Prefix OCE ===

Prefix/Len: 192.168.12.0/24

Next Obj Type: OBJ_SDWAN_NH_SLA_CLASS

Next Obj Handle: 0xf800045f, urpf: 0

Prefix Flags: unknown

aom id: 1717, HW handle: 0x561b60eeba20 (created)

El prefijo de interés apunta al objeto de siguiente salto del tipo de clase de acuerdo de nivel de servicio (SLA) (OBJ_SDWAN_NH_SLA_CLASS) con ID 0xf800045f que se puede verificar más a fondo. Aquí se muestra:

cE1#show platform software sdwan F0 next-hop sla id 0xf800045f

SDWAN Nexthop OCE

SLA: num_class 16, client_handle 0x561b610c3f10, ppe addr 0xdbce6c10

SLA_0: num_nhops 1, Fallback_sla_flag TDL_FALSE, nhobj_type SDWAN_NH_INDIRECT

ECMP: 0xf800044f 0xf800044f 0xf800044f 0xf800044f

0xf800044f 0xf800044f 0xf800044f 0xf800044f

0xf800044f 0xf800044f 0xf800044f 0xf800044f

0xf800044f 0xf800044f 0xf800044f 0xf800044f

SLA_1: num_nhops 0, Fallback_sla_flag TDL_FALSE, nhobj_type ADJ_DROP

ECMP: 0xf800000f 0xf800000f 0xf800000f 0xf800000f

0xf800000f 0xf800000f 0xf800000f 0xf800000f

0xf800000f 0xf800000f 0xf800000f 0xf800000f

0xf800000f 0xf800000f 0xf800000f 0xf800000f

Este es un resultado largo, por lo que se omitieron las clases de SLA del 2 al 15 porque no hay clases de SLA de reserva configuradas y todas apuntan a la misma adyacencia DROP especial que SLA 1. El interés principal es el objeto de salto siguiente de tipo indirecto (SDWAN_NH_INDIRECT) de SLA 0. También podemos observar que no hay ECMP y que todos los ID son iguales (0xf800044f). Se puede verificar aún más para encontrar la VPN de destino final y la etiqueta de servicio.

cE1#show platform software sdwan F0 next-hop indirect id 0xf800044f

SDWAN Nexthop OCE

Indirect: client_handle 0x561b610f8140, ppe addr 0xd86b4cf0

nhobj_type: SDWAN_NH_LOCAL_SLA_CLASS, nhobj_handle: 0xf808037f

label: 1007, vpn: 20, sys-ip: 169.254.206.12, vrf_id: 1, sla_class: 1

Método 3. Para encontrar la VPN de destino con la ayuda de la herramienta de seguimiento de paquetes

Otra manera de encontrar una VPN de destino es una herramienta de seguimiento de paquetes que puede analizar los paquetes reales que se ejecutan a través del router en tiempo real. La condición de depuración se configura para que coincida el tráfico sólo hacia/desde la dirección IP 192.168.12.12.

cE1#debug platform condition ipv4 192.168.12.12/32 both

cE1#debug platform packet-trace packet 10

Please remember to turn on 'debug platform condition start' for packet-trace to work

cE1#debug platform condition start

A continuación, si el tráfico se inició desde R30 con la ayuda de ping, puede ver los paquetes coincidentes en cE1 y verificar cada detalle del paquete. En este caso, es el primer número de paquete 0, por ejemplo. Las líneas más importantes se resaltan con los signos <<<<<.

cE1#show platform packet-trace summary

Pkt   Input                     Output                    State  Reason

0     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)

1     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)

2     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)

3     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)

4     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)

5     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)

cE1#show platform packet-trace packet 0

Packet: 0           CBUG ID: 0

Summary

Input     : GigabitEthernet6

Output    : Tunnel3

State     : DROP 52  (FirewallL4Insp) <<<<<<<<<<<<<<<<<<<<<<<<

Timestamp

Start   : 161062920614751 ns (03/24/2022 16:19:31.754050 UTC)

Stop    : 161062920679374 ns (03/24/2022 16:19:31.754114 UTC)

Path Trace

Feature: IPV4(Input)

Input       : GigabitEthernet6

Output      :

Source      : 192.168.30.30

Destination : 192.168.12.12

Protocol    : 1 (ICMP)

Feature: SDWAN Forwarding

SDWAN adj OCE:

Output       : GigabitEthernet3

Hash Value   : 0xda

Encap        : ipsec

SLA          : 0

SDWAN VPN    : 20

SDWAN Proto  : IPV4

Out Label    : 1007 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Local Color  : private2

Remote Color : private2

FTM Tun ID   : 218

SDWAN Session Info

SRC IP       : 192.168.10.11

SRC Port     : 12366

DST IP       : 192.168.10.12

DST Port     : 12346

Remote System IP : 169.254.206.12

Lookup Type : TUN_DEMUX

Service Type : NONE

Feature: ZBFW

Action  : Drop

Reason  : No Zone-pair found <<<<<<<<<<<<<<<<<<<<<<<<<<<<

Zone-pair name         : N/A <<<<<<<<<<<<<<<<<<<<<<<<<<<<

Class-map name         : N/A

Policy    name         : N/A

Input interface        : GigabitEthernet6

Egress interface       : Tunnel3

Input  VPN ID          : 30

Output VPN ID          : 20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Input  VRF ID:Name     : 1:30

Output VRF ID:Name     : 1:30

AVC Classification ID  : 0

AVC Classification name: N/A

UTD Context ID         : 0

Un seguimiento de paquetes indica que los cinco paquetes de eco ICMP enviados por ping se descartaron con el código de descarte 52 (FirewallL4Insp). Función de sección: SDWAN Forwarding indica que la VPN de destino es 20 y que la etiqueta de servicio 1007 en el encabezado interno del paquete tunelizado se utiliza para reenviar para designar la VPN de destino en cE2. Sección Característica: ZBFW confirma además que los paquetes se descartaron porque el par de zonas no se configuró para el tráfico de la entrada VPN 20 destinado a la zona VPN 30.

Posibles problemas debido a la conmutación por fallas

¿Qué sucede si la ruta 192.168.12.0/24 es retirada por R20 o ya no es accesible desde cE2 en VRF 20? Aunque desde una perspectiva de VRF 30, la subred es la misma, debido a que la política de seguridad de ZBFW trata el tráfico de la zona VPN 30 a las zonas VPN 20 y 10 de manera diferente, puede conducir a resultados no deseados como el tráfico permitido, mientras que no debe serlo o viceversa.

Por ejemplo, si simula una falla de un link entre los routers cE2 y R20. Esto lleva a la retirada de la ruta 192.168.12.0/24 de la tabla de routing VPN 20 en el controlador vSmart y, en su lugar, la ruta VPN 10 se filtra en la tabla de routing VPN 30. Se permite la conectividad de VPN 30 a VPN 10 según la política de seguridad aplicada en cE1 (esto se espera desde la perspectiva de la política de seguridad, pero no puede ser deseable para la subred específica presentada en ambas VPN).

cE1#show platform packet-trace packet 0

Packet: 0           CBUG ID: 644

Summary

Input     : GigabitEthernet6

Output    : GigabitEthernet3

State     : FWD

Timestamp

Start   : 160658983624344 ns (03/24/2022 16:12:47.817059 UTC)

Stop    : 160658983677282 ns (03/24/2022 16:12:47.817112 UTC)

Path Trace

Feature: IPV4(Input)

Input       : GigabitEthernet6

Output      :

Source      : 192.168.30.30

Destination : 192.168.12.12

Protocol    : 1 (ICMP)

Feature: SDWAN Forwarding

SDWAN adj OCE:

Output       : GigabitEthernet3

Hash Value   : 0xda

Encap        : ipsec

SLA          : 0

SDWAN VPN    : 10

SDWAN Proto  : IPV4

Out Label    : 1006

Local Color  : private2

Remote Color : private2

FTM Tun ID   : 188

SDWAN Session Info

SRC IP       : 192.168.10.11

SRC Port     : 12366

DST IP       : 192.168.10.12

DST Port     : 12346

Remote System IP : 169.254.206.12

Lookup Type : TUN_DEMUX

Service Type : NONE

Feature: ZBFW

Action  : Fwd

Zone-pair name         : ZP_VPN_30_VPN_10_VPN_30_to_10

Class-map name         : VPN_30_to_10-seq-11-cm_

Policy    name         : VPN_30_to_10

Input interface        : GigabitEthernet6

Egress interface       : Tunnel3

Input  VPN ID          : 30

Output VPN ID          : 10

Input  VRF ID:Name     : 1:30

Output VRF ID:Name     : 1:30

AVC Classification ID  : 0

AVC Classification name: N/A

UTD Context ID         : 0

Feature: IPSec

Result    : IPSEC_RESULT_SA

Action    : ENCRYPT

SA Handle : 74

Peer Addr : 192.168.10.12

Local Addr: 192.168.10.11

Observe que la etiqueta 1006 se utilizó en lugar de 1007 y el ID de VPN de salida es 10 en lugar de 20 ahora. Además, el paquete se permitía según la política de seguridad de ZBFW, y se daban los nombres de par de zonas, mapa de clase y política correspondientes.

Hay un problema aún mayor que puede surgir debido al hecho de que la ruta más antigua se mantiene en la tabla de ruteo de VPN 30 y en este caso es la ruta VPN 10 que después de la aplicación de política de control inicial la ruta VPN 20 se filtró en la tabla VPN 30 OMP en vSmart. Imagine el escenario en el que la idea original era exactamente la opuesta a la lógica de la política de seguridad de ZBFW descrita en este artículo. Por ejemplo, el objetivo era permitir el tráfico de VPN 30 a VPN 20 y no a VPN 10. Si se permitía después de una configuración de política inicial, después de la falla o del retiro de la ruta 192.168.12.0/24 de VPN 20, el tráfico permanece bloqueado a la subred 192.168.12.0/24 incluso después de la recuperación porque la ruta 192.168.12.0/24 aún se filtra de VPN 10.