Konfigurieren der zonenbasierten SD-WAN-Firewall (ZBFW) und des Route Leaking

Einleitung

In diesem Dokument wird beschrieben, wie die zonenbasierte Firewall (ZBFW) mit Route-Leaking zwischen Virtual Private Networks (VPN) konfiguriert, verifiziert und Fehler bei dieser behoben werden.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco SD-WAN-Overlay löst eine Erstkonfiguration aus
• ZBFW-Konfiguration über vManage User Interface (UI)
• Richtlinienkonfiguration für Route-Leaking-Kontrolle über die vManage-Benutzeroberfläche

Verwendete Komponenten 

Für die Demonstration wurde folgende Software verwendet:

• Cisco SD-WAN vSmart Controller mit Softwareversion 20.6.2
• Cisco SD-WAN vManage Controller mit Softwareversion 20.6.2
• Zwei Cisco IOS®-XE Catalyst 8000V Virtual Edge Platform Router mit 17.6.2 Softwareversion, die im Controller-Modus ausgeführt werden
• Drei virtuelle Edge-Plattform-Router Cisco IOS-XE Catalyst 8000V mit 17.6.2 Softwareversion, die im autonomen Modus ausgeführt werden

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

In diesem Dokument wird erläutert, wie der Router die Ziel-VPN-Zuordnung im SD-WAN-Overlay ermittelt und wie Routen-Leaking zwischen VPNs überprüft und behoben werden. Es beschreibt auch die Besonderheiten der Pfadauswahl, falls dasselbe Subnetz von einem anderen VPN aus angekündigt wird und welche Probleme dadurch entstehen können.

Konfigurieren

Netzwerkdiagramm

Beide SD-WAN-Router wurden mit grundlegenden Parametern konfiguriert, um Steuerverbindungen mit SD-WAN-Controllern und Verbindungen zwischen den Datenebenen herzustellen. Die Details dieser Konfiguration liegen außerhalb des Anwendungsbereichs dieses Dokuments. In der Tabelle hier sind die Zuweisungen für VPN, Standort-ID und Zonen zusammengefasst.

Für Router auf der Serviceseite wurden statische Standardrouten in jeder virtuellen Routing- und Weiterleitungsschnittstelle (Virtual Routing and Forwarding, VRF) konfiguriert, die auf den entsprechenden SD-WAN-Router verweist. Ebenso wurden SD-WAN-Edge-Router mit statischen Routen konfiguriert, die auf die entsprechenden Subnetze verweisen. Beachten Sie, dass zur Demonstration der potenziellen Probleme mit Route Leaking und ZBFW Router hinter der Serviceseite von cE2 dasselbe Subnetz 192.168.12.0/24 aufweisen. Auf beiden Routern hinter cE2 ist eine Loopback-Schnittstelle konfiguriert, um einen Host mit derselben IP-Adresse 192.168.12.12 zu emulieren.

Dabei ist zu beachten, dass die Cisco IOS-XE-Router R10, R20 und R30 auf den Serviceseiten der SD-WAN-Edge-Routen, die in dieser Demonstration hauptsächlich zur Emulation von End-Hosts dienen, im autonomen Modus ausgeführt werden. Loopback-Schnittstellen auf SD-WAN-Edge-Routen können für diesen Zweck nicht anstelle echter Hosts wie serviceseitiger Router verwendet werden, da Datenverkehr, der von einer Schnittstelle in einer VRF-Instanz eines SD-WAN-Edge-Routers stammt, nicht als Datenverkehr betrachtet wird, der von der entsprechenden ZBFW-Zone stammt und stattdessen zur speziellen Kernzone eines Edge-Routers gehört. Daher kann der ZBFW-Bereich nicht mit VRF identisch sein. Eine detaillierte Erörterung der Selbstzone liegt außerhalb des Rahmens dieses Artikels.

Konfiguration der Route Leaking

Das Hauptziel der Konfiguration der Kontrollrichtlinie besteht darin, das Route Leaking aller Routen von VPN 10 und 20 in VPN 30 zu ermöglichen. VRF 30 ist nur auf dem Router cE1 vorhanden, und VRFs 10 und 20 sind nur auf dem Router cE2 konfiguriert. Zu diesem Zweck wurden zwei Topologierichtlinien (benutzerdefinierte Steuerung) konfiguriert. Nachfolgend finden Sie die Topologie zum Exportieren aller Routen von VPN 10 und 20 in VPN 30.

Beachten Sie, dass die Standardaktion auf Zulassen eingestellt ist, um zu verhindern, dass TLOC-Meldungen oder normale Intra-VPN-Routing-Meldungen versehentlich blockiert werden.

Entsprechend wurde die Topologierichtlinie so konfiguriert, dass eine umgekehrte Ankündigung von Routing-Informationen von VPN 30 zu VPN 10 und 20 möglich ist.

Anschließend werden beide Topologierichtlinien den entsprechenden Standortlisten zugewiesen, und zwar in Richtung "Eingang" (eingehend). Routen von VPN 30 werden vom vSmart Controller in OMP-Tabellen (Overlay Management Protocol) von VPN 10 und 20 exportiert, wenn sie von cE1 empfangen werden (Standort-ID 11).

Ebenso werden Routen von VPN 10 und 20 von vSmart in die VPN 30-Routing-Tabelle exportiert, sobald VPN 10 und 20 Routen von cE2 empfangen wurden (Standort-ID 12).

Im Folgenden finden Sie eine Vorschau der vollständigen Control Policy-Konfiguration.

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
 !
!

Die Richtlinie muss im Abschnitt "vManage controller Configuration > Policies" (Konfiguration des vManage-Controllers > Richtlinien) aktiviert werden, damit sie auf dem vSmart-Controller wirksam wird.

ZBFW-Konfiguration

Hier ist eine Tabelle, die ZBFW zusammenfasst, um die Anforderungen für den Zweck der Demonstration in diesem Artikel zu filtern.

Das Hauptziel besteht darin, jeglichen ICMP-Verkehr (Internet Control Message Protocol) zuzulassen, der von der Serviceseite des Routers cE1 VPN 30 stammt und für VPN 10, nicht jedoch für VPN 20 bestimmt ist. Rückverkehr muss automatisch zugelassen werden.

Außerdem muss jeder ICMP-Datenverkehr vom serviceseitigen VPN 20 des Routers cE2 in das VPN 30 auf der Serviceseite von cE1 übertragen werden können, jedoch nicht von VPN 10. Rücksendungsdatenverkehr von VPN 30 an VPN 20 muss automatisch zugelassen werden.

Hier finden Sie die Vorschau der ZBFW-Richtlinien.

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
!

Um die Sicherheitsrichtlinie anzuwenden, muss sie im Dropdown-Menü "Sicherheitsrichtlinie" des Abschnitts "Zusätzliche Vorlagen" der Gerätevorlage zugewiesen werden.

Nach der Aktualisierung der Gerätevorlage wird die Sicherheitsrichtlinie auf dem Gerät aktiviert, auf das die Sicherheitsrichtlinie angewendet wurde. Für die Zwecke der Demonstration in diesem Dokument reichte es aus, Sicherheitsrichtlinien nur auf dem cE1-Router zu aktivieren.

Überprüfung

Jetzt müssen Sie überprüfen, ob die erforderlichen Sicherheitsrichtlinienziele (ZBFW) erreicht wurden.

Der Test mit Ping bestätigt, dass der Datenverkehr von Zone-VPN 10 zu VPN 30 erwartungsgemäß abgelehnt wird, da kein Zonenpaar für den Datenverkehr von VPN 10 zu VPN 30 konfiguriert ist.

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)

Entsprechend wird der Datenverkehr von VPN 20 zu VPN 30 zugelassen, wie in der Konfiguration der Sicherheitsrichtlinien erwartet.

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

Datenverkehr von VPN 30 zum Subnetz 192.168.10.0/24 in Zone-VPN 10 ist gemäß Richtlinienkonfiguration zulässig.

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

Datenverkehr von VPN 30 zu Subnetz 192.168.20.0/24 in Zone-VPN 20 wird abgelehnt, da kein Zonenpaar für diesen Datenverkehr konfiguriert ist, was erwartet wird.

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)

Weitere interessante Ergebnisse können Sie beobachten, wenn Sie versuchen, einen Ping an die IP-Adresse 192.168.12.12 zu senden, da sie sich in Zone VPN 10 oder VPN 20 befinden kann. Es ist unmöglich, das Ziel-VPN aus der Perspektive des Routers R30 auf der Serviceseite des SD-WAN-Edge-Routers cE1 zu bestimmen.

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)

Das Ergebnis ist für alle Quellen in VRF 30 gleich. Dies bestätigt, dass es nicht von den Ergebnissen der ECMP-Hashfunktion (Equal-Cost Multi-Path) abhängt:

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)

Basierend auf den Testergebnissen für die Ziel-IP-Adresse 192.168.12.12 können Sie nur vermuten, dass sie sich im VPN 20 befindet, da sie nicht auf die ICMP-Echo-Anfragen reagiert und höchstwahrscheinlich blockiert wird, da kein Zonenpaar konfiguriert ist, um den Datenverkehr von VPN 30 zu VPN 20 (wie gewünscht) zuzulassen. Wenn sich ein Ziel mit der gleichen IP-Adresse 192.168.12.12 im VPN 10 befindet und als Antwort auf eine ICMP-Echoanfrage angenommen wird, muss der Datenverkehr gemäß der ZBFW-Sicherheitsrichtlinie für den ICMP-Datenverkehr von VPN 30 zu VPN 20 zugelassen werden. Sie müssen das Ziel-VPN bestätigen.

Fehlerbehebung

Methode 1. So suchen Sie Ziel-VPN aus OMP-Tabelle

Eine einfache Überprüfung der Routing-Tabelle auf cE1 hilft nicht, das tatsächliche Ziel-VPN zu verstehen. Die nützlichsten Informationen, die Sie aus der Ausgabe erhalten können, ist eine System-IP-Adresse des Ziels (169.254.206.12) und dass kein ECMP stattfindet.

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

Um das Ziel-VPN herauszufinden, muss zuerst das Service-Label aus der OMP-Tabelle auf cE1 für das gewünschte Präfix ermittelt werden.

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  -

Wie Sie sehen, ist der Labelwert 1007. Schließlich kann ein Ziel-VPN gefunden werden, wenn alle Dienste, die vom Router mit der System-IP-Adresse 169.254.206.12 stammen, auf dem vSmart-Controller überprüft werden.

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

Anhand des VPN-Labels 1007 kann bestätigt werden, dass das Ziel-VPN 20 ist.

Methode 2. Suchen des Ziel-VPN mithilfe von Plattformbefehlen

Um mithilfe von Plattformbefehlen das Ziel-VPN herauszufinden, müssen Sie zunächst mithilfe von show ip vrf detail 30 oder show platform software ip f0 cef table * summary commands eine interne VRF-ID für VPN 30 auf dem cE1-Router erhalten.

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)

In diesem Fall wurde die VRF-ID 1 der VRF-Instanz 30 zugewiesen. Plattformbefehle zeigen die OCE-Kette (Output Chain Element) von Objekten in der SD-WAN-Software an, die eine interne Weiterleitungslogik darstellen, die den Paketpfad in der Cisco IOS-XE-Software bestimmt:

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)

Das Präfix von Interesse verweist auf das Next-Hop-Objekt des SLA-Klassentyps (OBJ_SDWAN_NH_SLA_CLASS) mit der ID 0xf800045f, das weiter verifiziert werden kann, ist hier dargestellt:

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

Dies ist eine lange Ausgabe, daher wurden SLA-Klassen von 2 bis 15 übersprungen, da keine Fallback-SLA-Klassen konfiguriert sind, und alle verweisen auf die gleiche spezielle DROP-Adjacency wie SLA 1. Das Hauptinteresse gilt dem Next-Hop-Objekt des indirekten Typs (SDWAN_NH_INDIRECT) von SLA 0. Es gibt auch keinen ECMP, und alle IDs sind identisch (0xff 800044f). Es kann weiter verifiziert werden, um das endgültige Ziel-VPN und das Service-Label zu finden.

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

Methode 3. So finden Sie mithilfe des Packet-Trace-Tools ein Ziel-VPN

Eine weitere Möglichkeit, ein Ziel-VPN zu finden, ist ein Paket-Trace-Tool, das echte Pakete analysieren kann, die den Router in Echtzeit durchlaufen. Die Debug-Bedingung ist so festgelegt, dass der Datenverkehr nur zur/von der IP-Adresse 192.168.12.12 übereinstimmt.

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

Wenn der Datenverkehr anschließend von R30 mithilfe von Ping initiiert wurde, können Sie übereinstimmende Pakete auf cE1 anzeigen und die Paketdetails überprüfen. In diesem Fall ist es beispielsweise die allererste Paketnummer 0. Die wichtigsten Linien sind mit <<<< Zeichen hervorgehoben.

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 

Ein Packet-Trace teilt mit, dass alle fünf ICMP-Echo-Pakete, die durch Ping gesendet wurden, mit dem Drop-Code 52 (FirewallL4Insp) verworfen wurden. Abschnitt-Funktion: SDWAN Forwarding gibt an, dass das Ziel-VPN 20 ist und das Service-Label 1007 im internen Header des getunnelten Pakets für die Weiterleitung verwendet wird, um das Ziel-VPN auf cE2 festzulegen. Abschnitt Funktion: ZBFW bestätigt außerdem, dass Pakete verworfen wurden, weil das Zonenpaar nicht für den Datenverkehr vom Eingangs-VPN 20 konfiguriert wurde, der an die VPN-30-Zone gerichtet ist.

Mögliche Probleme aufgrund von Failover

Was passiert, wenn die Route 192.168.12.0/24 von R20 entfernt wird oder von cE2 in VRF 20 nicht mehr erreichbar ist? Aus Sicht von VRF 30 ist das Subnetz zwar dasselbe, da die ZBFW-Sicherheitsrichtlinie den Datenverkehr von Zone VPN 30 zu Zonen VPN 20 und 10 unterschiedlich behandelt, es kann jedoch zu unerwünschten Ergebnissen wie dem zulässigen Datenverkehr führen, was nicht der Fall sein darf oder umgekehrt.

Wenn Sie beispielsweise den Ausfall einer Verbindung zwischen cE2- und R20-Routern simulieren. Dies führt zur Entnahme der Route 192.168.12.0/24 aus der VPN 20-Routing-Tabelle auf dem vSmart-Controller. Stattdessen wird die VPN 10-Route in die VPN 30-Routing-Tabelle eingespeist. Verbindungen von VPN 30 zu VPN 10 sind gemäß der auf cE1 angewendeten Sicherheitsrichtlinie zulässig (dies wird aus Sicherheitsrichtliniensicht erwartet, kann jedoch für das in beiden VPNs präsentierte spezifische Subnetz nicht wünschenswert sein).

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

Beachten Sie, dass statt 1007 das Label 1006 verwendet wurde und die Ausgangs-VPN-ID jetzt 10 anstatt 20 lautet. Außerdem wurde das Paket gemäß der ZBFW-Sicherheitsrichtlinie zugelassen, und es wurden die entsprechenden Zonenpaare, Klassenzuordnungen und Richtliniennamen angegeben.

Ein noch größeres Problem kann dadurch entstehen, dass die früheste Route in der Routing-Tabelle von VPN 30 verbleibt. In diesem Fall ist es die VPN 10-Route, die nach der ersten Kontrollrichtlinienanwendung VPN 20-Route in die VPN 30 OMP-Tabelle von vSmart geleakt wurde. Stellen Sie sich das Szenario vor, in dem die ursprüngliche Idee genau das Gegenteil der in diesem Artikel beschriebenen ZBFW-Sicherheitslogik war. Das Ziel bestand z. B. darin, Datenverkehr von VPN 30 zu VPN 20 und nicht zu VPN 10 zuzulassen. Wenn dies nach einer anfänglichen Richtlinienkonfiguration zugelassen wurde, bleibt der Datenverkehr nach dem Ausfall oder der Routenentziehung durch 192.168.12.0/24 von VPN 20 zum Subnetz 192.168.12.0/24 auch nach der Wiederherstellung blockiert, da die Route 192.168.12.0/24 weiterhin aus VPN 10 undicht wird.