SD-WAN Zone-Based Firewall (ZBFW) en routelektraliteit configureren

Inleiding

In dit document wordt beschreven hoe u Zone-Based Firewall (ZBFW) configureert, verifieert en problemen oplost met Route-lekken tussen Virtual Private Networks (VPN).

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Cisco SD-WAN-overlay brengt een eerste configuratie naar voren
• ZBFW-configuratie van vManage User Interface (UI)
• Beleidsconfiguratie voor weglekbeheer vanuit vManage UI

Gebruikte componenten 

Voor de demonstratie werd deze software gebruikt:

• Cisco SD-WAN vSmart-controller met 20.6.2 Softwarerelease
• Cisco SD-WAN vManage-controller met 20.6.2-softwarerelease
• Twee Cisco IOS®-XE Catalyst 8000V virtuele edge platform routers met 17.6.2 Software Release die in controller modus draaien
• Drie Cisco IOS-XE Catalyst 8000V virtuele edge platform routers met 17.6.2 Software Release die in autonome modus draaien

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

In dit document wordt uitgelegd hoe de router de toewijzing van bestemmings-VPN's in de SD-WAN-overlay bepaalt en hoe het lekken van routes tussen VPN's kan worden geverifieerd en opgelost. Het beschrijft ook de eigenaardigheden van padselectie in het geval dat hetzelfde subnet wordt geadverteerd vanuit een andere VPN en wat voor soort problemen hierdoor kunnen ontstaan.

Configureren

Netwerkdiagram

Beide SD-WAN-routers werden geconfigureerd met basisparameters om besturingsverbindingen met SD-WAN-controllers en gegevensvliegtuigverbindingen tussen hen tot stand te brengen. Details van deze configuratie vallen buiten het bereik van dit document. De tabel hier geeft een overzicht van de VPN-, Site-ID- en Zones-toewijzingen.

Routers aan de servicekant werden geconfigureerd met statische standaardroutes in elke virtuele routering en doorsturen (VRF) die verwijst naar de SD-WAN-router die overeenkomt. Op dezelfde manier werden SD-WAN Edge-routers geconfigureerd met statische routes die verwijzen naar de subnetten die corresponderen. Merk op dat routers achter de dienstzijde van cE2 hetzelfde subnet 192.168.12.0/24 hebben om de potentiële problemen met routelekanalen en ZBFW aan te tonen. Op beide routers achter cE2 is er een Loopback-interface geconfigureerd om een host met hetzelfde IP-adres 192.168.12.12 na te bootsen.

Het is belangrijk op te merken dat de Cisco IOS-XE-routers R10, R20 en R30 in autonome modus draaien op de servicezijden van SD-WAN Edge-routes die voornamelijk dienen om eindhosts in deze demonstratie na te bootsen. Loopback-interfaces op SD-WAN Edge-routes kunnen niet voor dit doel worden gebruikt in plaats van echte hosts zoals routers aan de servicekant, omdat verkeer dat afkomstig is van een interface in een VRF van SD-WAN Edge-router niet wordt beschouwd als verkeer dat afkomstig is uit de ZBFW-zone die overeenkomt en eerder behoort tot de speciale zelfzone van een edge-router. Daarom kan de ZBFW-zone niet als hetzelfde worden beschouwd als VRF. Een gedetailleerde bespreking van de zelfzone valt buiten het toepassingsgebied van dit artikel.

configuratie van routelektronen

Het belangrijkste doel van het configuratiebeleid is om routelektraliteit van alle routes van VPN 10 en 20 naar VPN 30 mogelijk te maken. VRF 30 bestaat alleen op de router cE1 en VRF's 10 en 20 zijn alleen geconfigureerd op de router cE2. Hiervoor zijn twee topologiebeleidsregels (Aangepast beheer) geconfigureerd. Hier is de topologie om alle routes van VPN 10 en 20 naar VPN 30 te exporteren.

Merk op dat de standaardactie is ingesteld op Toestaan, om te voorkomen dat TLOC-advertenties of normale intra-VPN-routes per ongeluk worden geblokkeerd.

Ook is het topologiebeleid zo geconfigureerd dat het mogelijk is om omgekeerde reclame van routeringsinformatie van VPN 30 naar VPN 10 en 20 toe te staan.

Vervolgens worden beide topologiebeleidsregels toegewezen aan de sitelijsten die overeenkomen, in de ingangen (inkomende) richting. Routes van VPN 30 worden door de vSmart-controller geëxporteerd naar Overlay Management Protocol (OMP)-tabellen van VPN 10 en 20 wanneer ze worden ontvangen van cE1 (site-id 11).

Op dezelfde manier worden routes van VPN 10 en 20 door vSmart geëxporteerd naar de VPN 30-routeringstabel bij ontvangst van VPN 10 en 20-routes van cE2 (site-id 12).

Hier vindt u ook een voorbeeld van de configuratie van het volledige controlebeleid ter referentie.

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

Het beleid moet worden geactiveerd in de sectie Configuratie > Beleid van vManage-controller om effectief te zijn op de vSmart-controller.

ZBFW-configuratie

Hier is een tabel die ZBFW samenvat om de vereisten voor demonstratiedoeleinden in dit artikel te filteren.

Het belangrijkste doel is om elk Internet Control Message Protocol (ICMP) verkeer toe te staan dat afkomstig is van de servicezijde van router cE1 VPN 30 en is bestemd voor VPN 10, maar niet voor VPN 20. Retourverkeer moet automatisch worden toegestaan.

Ook moet elk ICMP-verkeer van de router cE2 service-side VPN 20 worden toegestaan om over te gaan naar VPN 30 service-side van cE1, maar niet van VPN 10. Retourverkeer van VPN 30 naar VPN 20 moet automatisch worden toegestaan.

Hier kunt u de ZBFW policy preview ter referentie vinden.

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
!

Als u beveiligingsbeleid wilt toepassen, moet dit worden toegewezen in het vervolgkeuzemenu Veiligheidsbeleid van het gedeelte Aanvullende sjablonen van de apparaatsjabloon.

Zodra de apparaatsjabloon is bijgewerkt, wordt het beveiligingsbeleid actief op het apparaat waarop het beveiligingsbeleid is toegepast. Voor de demonstratie in dit document was het voldoende om alleen het beveiligingsbeleid op de cE1-router in te schakelen.

Verifiëren

Nu moet u controleren of de vereiste doelstellingen van het beveiligingsbeleid (ZBFW) zijn bereikt.

Test met ping bevestigt dat het verkeer van zone VPN 10 naar VPN 30 wordt geweigerd zoals verwacht, omdat er geen zone-paar is geconfigureerd voor verkeer van VPN 10 naar 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)

Op dezelfde manier is verkeer van VPN 20 toegestaan naar VPN 30, zoals verwacht door de configuratie van het beveiligingsbeleid.

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

Verkeer van VPN 30 naar subnet 192.168.10.0/24 in zone VPN 10 is toegestaan zoals verwacht door de beleidsconfiguratie.

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

Verkeer van VPN 30 naar subnet 192.168.20.0/24 in zone VPN 20 wordt geweigerd omdat er geen zonepaar is geconfigureerd voor dit verkeer, wat wordt verwacht.

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)

Aanvullende resultaten die u kunnen interesseren, kunnen worden waargenomen wanneer u probeert het IP-adres 192.168.12.12 te pingen, omdat het zich in zone VPN 10 of VPN 20 kan bevinden en het onmogelijk is om de bestemming VPN te bepalen vanuit het perspectief van de router R30 die zich aan de servicekant van SD-WAN edge router cE1 bevindt.

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)

Het resultaat is hetzelfde voor alle bronnen in VRF 30. Dit bevestigt dat het niet afhankelijk is van de resultaten van de Equal-Cost Multi-Path (ECMP)-hashfunctie:

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)

Op basis van testresultaten voor de bestemming IP 192.168.12.12, kunt u alleen raden dat het zich in VPN 20 bevindt, omdat het niet reageert op de ICMP-echoverzoeken en hoogstwaarschijnlijk wordt geblokkeerd omdat er geen zone-paar is geconfigureerd om verkeer van VPN 30 naar VPN 20 toe te staan (zoals gewenst). Als een bestemming met hetzelfde IP-adres 192.168.12.12 zich in VPN 10 zou bevinden en aangenomen zou worden te reageren op ICMP-echoverzoek, dan moet volgens het ZBFW-beveiligingsbeleid voor ICMP-verkeer van VPN 30 naar VPN 20 verkeer worden toegestaan. U moet de VPN-bestemming bevestigen.

Problemen oplossen

Methode 1. Bestemmings-VPN zoeken in OMP-tabel

Een eenvoudige controle van de routeringstabel op cE1 helpt niet om de daadwerkelijke bestemming VPN te begrijpen. De meest bruikbare informatie die u kunt krijgen van de uitvoer is een systeem-IP van de bestemming (169.254.206.12) en ook dat er geen ECMP gebeurt.

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

Om de VPN-bestemming te achterhalen, moet u eerst het servicelabel van de OMP-tabel op cE1 vinden voor het voorvoegsel van belang.

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  -

We kunnen zien dat de labelwaarde 1007 is. Tot slot kan destination VPN worden gevonden als alle services die afkomstig zijn van de router die systeem-IP 169.254.206.12 bezit, worden gecontroleerd op de vSmart-controller.

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

Op basis van VPN-label 1007 kan worden bevestigd dat de bestemming VPN 20 is.

Methode 2. Bestemmings-VPN vinden met behulp van platformopdrachten

Om de VPN-bestemming te achterhalen met behulp van platformopdrachten, moet u eerst een interne VRF-ID voor VPN 30 op de cE1-router verkrijgen met behulp van ip vrf detail 30 tonen of platformsoftware ip f0 cef-tabel * samenvatting opdrachten.

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 dit geval werd VRF ID 1 toegewezen aan VRF met de naam 30. Platformcommando's onthullen de Output Chain Element (OCE)-keten van objecten in SD-WAN-software die de interne doorstuurlogica vertegenwoordigt die het pakketpad bepaalt in Cisco IOS-XE-software:

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)

Het prefix van interest verwijst naar het next-hop object van het klasse type Service Level Agreement (SLA) (OBJ_SDWAN_NH_SLA_CLASS) met ID 0xf800045f dat verder kan worden geverifieerd, wordt hier weergegeven:

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

Dit is een lange uitvoer, dus SLA-klassen van 2 tot 15 werden overgeslagen omdat er geen Fallback SLA-klassen zijn geconfigureerd en ze wijzen allemaal op dezelfde speciale DROP-nabijheid als SLA 1. Het hoofdbelang is het next-hop object van indirect type (SDWAN_NH_INDIRECT) uit SLA 0. We kunnen ook opmerken dat er geen ECMP is en dat alle ID's hetzelfde zijn (0xf800044f). Het kan verder worden geverifieerd om de ultieme bestemming en het VPN-servicelabel te vinden.

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. Bestemmings-VPN vinden met behulp van Packet-Trace Tool

Een andere manier om een VPN-bestemming te vinden, is een packet-trace-tool die echte pakketten kan analyseren die in realtime door de router lopen. De foutopsporingsvoorwaarde is ingesteld om alleen verkeer van/naar het IP-adres 192.168.12.12 aan te passen.

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

Vervolgens, als het verkeer is gestart vanaf R30 met behulp van ping, kunt u overeenkomende pakketten op cE1 zien en elk pakketdetail controleren. In dit geval is het bijvoorbeeld het allereerste pakketnummer 0. De belangrijkste regels worden gemarkeerd met <<<< tekens.

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 

Een packet-trace vertelt dat alle vijf ICMP echo pakketten verzonden door ping werden gedropt met drop code 52 (FirewallL4Insp). Sectie functie: SDWAN Forwarding vertelt dat de bestemming VPN 20 is en service label 1007 in de interne header van het getunnelde pakket wordt gebruikt om door te sturen naar bestemming VPN op cE2. Sectie Functie: ZBFW bevestigt verder dat pakketten zijn verwijderd omdat het zonepaar niet is geconfigureerd voor verkeer van Input VPN 20 bestemd voor VPN 30-zone.

Mogelijke problemen door failover

Wat gebeurt er als route 192.168.12.0/24 wordt ingetrokken door R20 of niet meer bereikbaar is vanaf cE2 in VRF 20? Hoewel vanuit het perspectief van VRF 30 het subnet hetzelfde is, omdat het ZBFW-beveiligingsbeleid verkeer van zone VPN 30 naar zones VPN 20 en 10 anders behandelt, kan dit leiden tot ongewenste resultaten zoals verkeer toegestaan, terwijl dit niet mag zijn of vice versa.

Als u bijvoorbeeld een storing van een koppeling tussen cE2- en R20-routers simuleert. Dit leidt tot 192.168.12.0/24 route terugtrekking uit VPN 20 routering tabel op vSmart controller en in plaats daarvan, VPN 10 route is gelekt in VPN 30 routering tabel. Connectiviteit van VPN 30 naar VPN 10 is toegestaan volgens het beveiligingsbeleid dat wordt toegepast op cE1 (dit wordt verwacht vanuit het perspectief van het beveiligingsbeleid, maar kan niet wenselijk zijn voor het specifieke subnet dat in beide VPN's wordt gepresenteerd).

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

Merk op dat label 1006 werd gebruikt in plaats van 1007 en dat de output VPN ID nu 10 is in plaats van 20. Ook was het pakket toegestaan volgens het ZBFW-beveiligingsbeleid en werden de bijbehorende zone-pair, class-map en beleidsnamen gegeven.

Er is een nog groter probleem dat kan ontstaan als gevolg van het feit dat de vroegste route wordt bewaard in de routeringstabel van VPN 30 en in dit geval is het de VPN 10-route die na de eerste controlebeleidsapplicatie VPN 20-route is gelekt in VPN 30 OMP-tabel op vSmart. Stel je het scenario voor waarin het oorspronkelijke idee precies het tegenovergestelde was van de logica van het ZBFW-veiligheidsbeleid die in dit artikel wordt beschreven. Het doel was bijvoorbeeld om verkeer van VPN 30 naar VPN 20 toe te staan en niet naar VPN 10. Als het was toegestaan na een eerste beleidsconfiguratie, dan na de storing of 192.168.12.0/24 route terugtrekking van VPN 20, blijft het verkeer geblokkeerd naar het 192.168.12.0/24 subnet, zelfs na herstel, omdat de 192.168.12.0/24 route nog steeds lekt van VPN 10.