DHCP Relay over SDWAN issue

[MoAb123]

Hello all,

DHCP relay is configured on the firewall over SDWAN the device acquire the IP normally but after some days it stop working and need to clear the session so any device can acquire an IP.

The DHCP relay was working fine before implanting the SDWAN no issues at all but after the integration of SDWAN the issue start so what could be wrong which led to this behavior.

PA-410> 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])
--------------------------------------------------------------------------------
16250        dhcp           ACTIVE  FLOW       172.16.12.1[67]/LAN/17  (172.16.12.1[67])
vsys1                                          192.168.3.200[67]/zone-to-hub  (192.168.3.200[67])
14499        dhcp           ACTIVE  FLOW       172.16.12.1[67]/LAN/17  (172.16.12.1[67])
vsys1                                          192.168.0.200[67]/zone-to-hub  (192.168.0.200[67])

no discard state but DHCP sessions seem to be stuck in the firewall, and that these sessions have been active for more than 6 hours. 

 PA-410 > show session id 16250

Session           16250

        c2s flow:
                source:      172.16.12.1 [LAN]
                dst:         192.168.3.200
                proto:       17
                sport:       67              dport:      67
                state:       ACTIVE          type:       FLOW
                src user:    unknown
                dst user:    unknown
                fwd cache:   {FIB} cached
                        fib: 12587 hit(s), 93 miss(es)
                sdwan rule:  N/A             path:       tunnel.915
                sdwan FEC:   Unknown

        s2c flow:
                source:      192.168.3.200 [zone-to-hub]
                dst:         172.16.12.1
                proto:       17
                sport:       67              dport:      67
                state:       ACTIVE          type:       FLOW
                src user:    unknown
                dst user:    unknown
                sdwan rule:  N/A             path:       [N/A]

        start time                           : Mon Dec  8 08:03:13 2025
        timeout                              : 30 sec
        time to live                         : 28 sec
        total byte count(c2s)                : 4126161
        total byte count(s2c)                : 32774
        layer7 packet count(c2s)             : 11919
        layer7 packet count(s2c)             : 93
        vsys                                 : vsys1
        application                          : dhcp
        rule                                 : ACCESS  
        service timeout override(index)      : False
        session to be logged at end          : True
        session in session ager              : True
        session updated by HA peer           : False
        software fast forwarding             : False
        layer7 processing                    : enabled
        ctd version                          : 3

PAN-OS 11.1.10-h1
SDWAN plugin version 3.2.3-h2
 

[SamirAhemed]

This is known behaviour, Its get trigger only when there is changes in routing/Forwarding of traffic.
UDP session is not automatic get clear once there is any routing change.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HBmqCAG 
enable "set session teardown-upon-fwd-zonechange yes" will help

[WtrN06]

We encountered the same issue where the DHCP-relay service started sending traffic via the default route (ISP) instead of via SDWAN (zone-to-hub) because the SDWAN-tunnel was not active yet.

Because Palo Alto treats UDP traffic as a session, it keeps that session active in the wrong zone (ISP in this case). As a result, the traffic continues to follow the incorrect path.

Once you manually clear that "session", the traffic immediately shifts back to the correct SD-WAN zone (zone-to-hub).

Enabling "set session teardown-upon-fwd-zonechange yes" does NOT help in my case.

I eventually made my own workaround by creating a custom service which terminates that UDP-'session' withing 2 minutes when idle (no response from DHCP-server)

This service is then used in a security policy on the branch office firewall with destination-zone the correct AND wrong zone (ISP and zone-to-hub in my case).

The root cause is still not resolved, but it no longer requires manual intervention to mitigate the issue.

[SamirAhemed]

Thanks for sharing valuable information. 
I just have 1 question, Default timeout value for UDP is 30 Sec, Creating service for UDP with 120 Sec again contribute to issue.

[WtrN06]

Although there is a “technical” difference between a session timeout and an idle timeout, I fully agree with you.

Both timers should lead to the same outcome. 

However, I believe this behavior only holds when the route remains unchanged during the active data flow.

The issue appears specifically when traffic is actively flowing while being redirected at the same time (e.g., route change, zone change, etc.).

[SamirAhemed]

That's right, its trigger only whenever there is changes in routing/Failover of firewalls.
we have dual ISP wherein both ISP within same zone using NAT.
in our case when routes fail, interface Change but sessions  shows  old NAT IP of ISP link which is down.
As soon as we clear sessions it resolve issue.