DHCP Sitzungen zwischen Zweigstellen, FW die als DHCP Relay konfiguriert sind, und DHCP Server am Hub Standort gehen nach einem Stromausfall in den DISCARD Status über.

• Clientgeräte in Zweigstellen können keine Adressen abrufen IP
• Am Standort der Zweigstelle werden Sitzungen zwischen dem (DHCPRelay) und dem FW DHCP Server am Hub Standort FWDHCP als in einem DISCARD Zustand angezeigt

admin@Lab70-158-PA-220> show session all filter application dhcp

--------------------------------------------------------------------------------
ID          Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port])
Vsys                                          Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
64858        dhcp           DISCARD FLOW  NS   192.168.2.1[67]/L3-Trust/17  (10.129.72.158[53110])
vsys1                                          192.168.1.5[67]/L3-Untrust  (192.168.1.5[67])

• DISCARD Session-End-Grund ist policy-deny aufgrund von appid policy lookup deny

admin@Lab70-158-PA-220> show session id 64858

Session           64858

        c2s flow:
                source:      192.168.2.1 [L3-Trust]
                dst:         192.168.1.5
                proto:       17
                sport:       67              dport:      67
                state:       DISCARD         type:       FLOW
                src user:    unknown
                dst user:    unknown

        s2c flow:
                source:      192.168.1.5 [L3-Untrust]
                dst:         10.129.72.158
                proto:       17
                sport:       67              dport:      53110
                state:       DISCARD         type:       FLOW
                src user:    unknown
                dst user:    unknown

        start time                           : Fri Jan 28 04:23:30 2022
        timeout                              : 60 sec
        time to live                         : 58 sec 
        total byte count(c2s)                : 8312
        total byte count(s2c)                : 0
        layer7 packet count(c2s)             : 24
        layer7 packet count(s2c)             : 0
        vsys                                 : vsys1
        application                          : dhcp  
        rule                                 : vsys1+interzone-default
        service timeout override(index)      : False
        session to be logged at end          : True
        session in session ager              : True
        session updated by HA peer           : False
        address/port translation             : source
        nat-rule                             : Trust-NAT(vsys1)
        layer7 processing                    : enabled
        URL filtering enabled                : False
        session via syn-cookies              : False
        session terminated on host           : True
        session traverses tunnel             : False
        session terminate tunnel             : False
        captive portal session               : False
        ingress interface                    : ethernet1/2
        egress interface                     : ethernet1/1
        session QoS rule                     : N/A (class 4)
        tracker stage firewall               : appid policy lookup deny
        end-reason                           : policy-deny

• NGFW Firewall
• LSVPN
• Dynamisches Routing zwischen hub und Satellitenstandorten mit BGP
• Der Zweigstellenstandort firewall verfügt über eine Schnittstelle, die als DHCP Relay konfiguriert ist

• DHCP (UDP) Die Sitzung wird anfänglich erstellt/zugelassen, wenn der Tunnel aktiv ist (entspricht der erwarteten Sicherheit policy) und den Tunnel durchläuft (Zonen: Trust -> Trust)
• Wenn der Tunnel ausfällt, BGP wird die gelernte Route (über Tunnel-Peering) entfernt und die Standardroute wird wirksam
• Neuer DHCP Datenverkehr erstellt eine neue Sitzung (langsamer Pfad) über eine "potenzielle" Sicherheitsübereinstimmung, entscheidet sich jedoch nach dem appAusführen firewall von -id für eine DISCARD Sitzung (wie erwartet, basierend auf den vorhandenen Sicherheitsrichtlinienpolicy) (Zonen: Vertrauen -> Nicht vertrauenswürdigDHCP; nicht zulässig)
• Da die Sitzung vor der Sitzungserstellung nicht blockiert wird (aufgrund einer möglichen Übereinstimmung vor appder Bestimmung von -id), DISCARD wird die Sitzung mit neuem Datenverkehr mit dem gleichen 6-Tupel aktualisiert
• Wenn der Tunnel wieder verfügbar ist, kann es sein, dass der Datenverkehr immer noch die alte (DISCARD) Sitzung trifft/aktualisiert, sodass die neue Sitzung nicht erstellt und DHCP der Datenverkehr weitergeleitet werden kann

1. Erstellen Sie oben eine strikte Verweigerungsregel, die auf die Richtung "Vertrauen" abzielt > "Nicht vertrauenswürdig", die auf dem Port basiert, und vermeiden Sie potenzielle Sicherheitsübereinstimmungen policy , bevor app-id ermittelt wird. Dadurch wird sichergestellt, dass der Datenverkehr in der Slowpath-Phase verweigert wird und keine Sitzung erstellt wird (die anschließend manuell gelöscht werden muss)
2. Ähnlich wie oben, aber mit DoS Policy mit "Deny" -Aktion; Es ist weniger ressourcenintensiv, da es vor den Sicherheitsrichtlinien verarbeitet wird, und wir können bestimmte Quell-/Zielpaare zuordnen
3. Erstellen Sie eine statische Nullroute (Verwerfen), die einer bestimmten Ziel-/Ausgangsschnittstelle mit geringerer Admin-Distanz als die Standardroute, aber höher als BGP die Route entspricht. In diesem Fall können wir mit source/port/app-id nicht so spezifisch sein