DHCP les sessions entre la branche FW configurée en tant que DHCP relais et DHCP le serveur à l’emplacement passent à Hub l’état DISCARD après une panne de courant.

• Les appareils clients de la succursale ne peuvent pas obtenir IP d’adresses
• Sur l’emplacement de la succursale, DHCP les sessions entre le FW (DHCPrelais) et le DHCP serveur à l’emplacement FWHub sont vues comme étant dans un DISCARD état

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 La raison de fin de session est policy-deny due to 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
• Routage dynamique entre hub et emplacements satellites à l’aide de BGP
• L’emplacement de la firewall succursale a une interface configurée en tant que DHCP relais

• DHCP (UDP) session est initialement créée/autorisée lorsque le tunnel est en place (correspondant à la sécurité policyattendue) et passe par le tunnel (zones : Trust -> Trust)
• Lorsque le tunnel tombe en panne, BGP l’itinéraire appris (via l’appairage de tunnel) est supprimé et l’itinéraire par défaut prend effet
• Le nouveau DHCP trafic crée une nouvelle session (slowpath) via une correspondance de sécurité « potentielle », mais après appl’exécution de -id, firewall décide de DISCARD session (comme prévu, en fonction des stratégies de sécurité policy en place) (zones: Trust -> Untrust; DHCP non autorisé)
• Étant donné que la session n'est pas bloquée avant la création de la session (en raison de la correspondance potentielle avant appque -id ne soit déterminé), DISCARD la session est actualisée avec un nouveau trafic avec le même 6-tuple
• Lorsque le tunnel est de retour, le trafic peut encore frapper / rafraîchir l’ancienne session (DISCARD), ce qui ne permet pas de créer la nouvelle session et DHCP de transférer le trafic

1. Créer une règle de refus stricte en haut ciblant la direction Trust -> Untrust basée sur le port, en évitant les correspondances de sécurité policy potentielles avant appque -id ne soit déterminé ; Cela garantira que le trafic est refusé dans la phase slowpath et ne crée pas de session (qui doit être effacée manuellement par la suite)
2. Similaire à ci-dessus, mais en utilisant DoS Policy avec l’action « Deny »; Il est moins gourmand en ressources car il est traité avant les politiques de sécurité, et nous pouvons faire correspondre des paires source / destination spécifiques
3. Créez un itinéraire statique nul (Rejeter) correspondant à une interface de destination/sortie spécifique avec une distance d’administration inférieure à celle de l’itinéraire par défaut, mais supérieure à l’itinéraire BGP ; Dans ce cas, nous ne pouvons pas être aussi précis avec source/port/app-id