Skip to main content
yzayani
Staff
yzayani
Staff
June 29, 2026

Troubleshooting Tip: DHCP server uses physical MAC instead of HA VMAC after reboot or upgrade

  • June 29, 2026
  • 0 replies
  • 157 views

Description

This article describes an issue where the FortiGate DHCP server sends DHCP Offer/Ack packets using the physical MAC address of the interface instead of the configured HA Virtual MAC (VMAC) after a reboot, upgrade, or power recovery event.

Scope

All FortiGate platforms in Active-Passive HA with a DHCP server enabled on an internal interface. Observed on FortiOS v7.2.x and v7.4.x.

Solution

  • In affected deployments, clients receiving DHCP leases from the FortiGate will see the physical MAC as the source of DHCP Offer/Ack frames instead of the expected HA VMAC.

  • This can break environments using DHCP snooping, as downstream switches learn the wrong source MAC.

  • The issue is specific to the DHCP server daemon (dhcpd) and not to the general HA MAC programming.
    The following confirms the affected state:

  1. HA cluster remains formed and in-sync.

  2. Non-DHCP traffic (e.g. ICMP) from the same interface uses the correct VMAC.

  3. DHCP sniffer shows the physical MAC as the Ethernet source in Offer/Ack frames.

diagnose sys ha mac

HA mac msg
Primary
prio=0, phy_index= 0, itf_name=  wan1, mac=e6.ab.c3.6a.fb.10, vmac=--.--.--.--.--.--, linkfbil=0
prio=0, phy_index= 1, itf_name=  wan2, mac=e6.ab.c3.6a.fb.11, vmac=--.--.--.--.--.--, linkfbil=0
prio=0, phy_index= 2, itf_name=internal1, mac=e6.ab.c3.6a.fb.12, vmac=00.09.0f.09.00.01, linkfbil=0
prio=0, phy_index= 3, itf_name=internal2, mac=e6.ab.c3.6a.fb.13, vmac=00.09.0f.09.00.02, linkfbil=1
prio=0, phy_index= 4, itf_name=internal3, mac=e6.ab.c3.6a.fb.14, vmac=00.09.0f.09.00.03, linkfbil=0
prio=0, phy_index= 5, itf_name=internal4, mac=e6.ab.c3.6a.fb.15, vmac=--.--.--.--.--.--, linkfbil=1
prio=0, phy_index= 6, itf_name=internal5, mac=e6.ab.c3.6a.fb.16, vmac=--.--.--.--.--.--, linkfbil=0
prio=0, phy_index= 7, itf_name=internal6, mac=e6.ab.c3.6a.fb.20, vmac=--.--.--.--.--.--, linkfbil=0
prio=0, phy_index= 8, itf_name=     a, mac=e6.ab.c3.6a.fb.18, vmac=00.09.0f.09.00.07, linkfbil=0
prio=0, phy_index= 9, itf_name=     b, mac=e6.ab.c3.6a.fb.19, vmac=--.--.--.--.--.--, linkfbil=0
prio=0, phy_index=11, itf_name=fortilink, mac=e6.ab.c3.6a.fb.19, vmac=00.09.0f.09.00.08, linkfbil=0
prio=0, phy_index=12, itf_name=   lan, mac=e6.ab.c3.6a.fb.15, vmac=00.09.0f.09.00.03, linkfbil=1
prio=0, phy_index=13, itf_name=WAN_INET, mac=e6.ab.c3.6a.fb.16, vmac=00.09.0f.09.00.04, linkfbil=0
prio=0, phy_index=14, itf_name=WAN_MPLS, mac=e6.ab.c3.6a.fb.20, vmac=00.09.0f.09.00.06, linkfbil=0
Secondary
prio=1, phy_index= 0, itf_name=  wan1, mac=86.d5.77.a5.a3.76, linkfbil=1
prio=1, phy_index= 1, itf_name=  wan2, mac=86.d5.77.a5.a3.85, linkfbil=1
prio=1, phy_index= 2, itf_name=internal1, mac=86.d5.77.a5.a3.86, linkfbil=0
prio=1, phy_index= 3, itf_name=internal2, mac=86.d5.77.a5.a3.87, linkfbil=1
prio=1, phy_index= 4, itf_name=internal3, mac=86.d5.77.a5.a3.88, linkfbil=1
prio=1, phy_index= 5, itf_name=internal4, mac=86.d5.77.a5.a3.89, linkfbil=1
prio=1, phy_index= 6, itf_name=internal5, mac=86.d5.77.a5.a3.8a, linkfbil=0
prio=1, phy_index= 7, itf_name=internal6, mac=86.d5.77.a5.a3.8b, linkfbil=0
prio=1, phy_index= 8, itf_name=     a, mac=76.d5.77.a5.a3.9c, linkfbil=0
prio=1, phy_index= 9, itf_name=     b, mac=76.d5.77.a5.a3.9d, linkfbil=1
prio=1, phy_index=11, itf_name=fortilink, mac=56.d5.77.a5.a3.9d, linkfbil=1
prio=1, phy_index=12, itf_name=   lan, mac=86.d5.77.a5.a3.99, linkfbil=1
prio=1, phy_index=13, itf_name=WAN_INET, mac=76.a5.77.b5.b3.9b, linkfbil=0
prio=1, phy_index=14, itf_name=WAN_MPLS, mac=76.a5.77.b5.b3.9c, linkfbil=0


  • This issue is resolved in FortiOS v7.6.8 and FortiOS v8.0.0.

      Terms & ConditionsAccessibility statement