Skip to main content
martyyy
martyyy
Explorer III
October 22, 2024
Solved

FortiGate ICMP ECHO before DHCP Offer

  • October 22, 2024
  • 1 reply
  • 2783 views

Hi,

Is it possible to have the Fortigate perform a ICMP-ECHO to a IP Address before it sends a DHCP Offer to a client device. Have had an issue with duplicate IP Addresses on overlapping scopes / ranges that have static IP Addresses configured. This could be resolved with the DHCP server testing to see if the IP address is already in use in advance rather than relying on the client device to perform this function, I.E sending out an arp before accepting the DHCP Offer.

 

Any help would be much appreciated, thankyou.

 

Best answer by pminarik

As I noted already: I only saw conflict detection via ARP message. I didn't see an ICMP attempt. ARP should be a better option anyway - devices aren't obliged to respond to pings, but they absolutely have to respond to ARP, if they want to function within that subnet.

 

(maybe there would be a follow-up ping if ARP succeeded, but the ARP request failing should be a sufficient sign of the IP being unused).

 

edit: For the sake of the exercise, I've intentionally introduced a potential for conflict, and here's what happened:

 

1, DHCP discover sent by client

2, FGT ARP-requests for potential IP

3, other device responds to ARP

4, FGT pings the potential IP

5, other device responds to ping

=> IP temporarily blacklisted

6, DHCP discover re-sent by client

7, FGT ARP-request for another potential IP

8, no ARP reply

9, FGT sends DHCP OFFER with this IP

...

 

So yes, the FortiGate will ping for the IP to be assigned, provided that the conflicting device is capable of responding to ARP requests (which it very much SHOULD).

 

The conflict appears to be cached for 30 minutes, based on the lease list output:

> execute dhcp lease-list

 

Hope it helps.

 

1 reply

pminarik
Staff
pminarik
Staff
October 22, 2024

I just did a quick test with a 7.6.0 VM, and it is already trying to prevent conflicts - it sends out an ARP request for an IP address before it offers it.

1, -> DHCP DISCOVER

2, ARP req for IP A.B.C.D (waiting approx 1 second for a reply)
3, <- DHCP OFFER (offering IP A.B.C.D)

...

    martyyy
    martyyyAuthor
    Explorer III
    October 23, 2024

    Hi @pminarik ,
    Thanks for the reply. I have FGT 71F and running in FortiOS 7.2 GA. Can the Fortigate either do this functionality or can it not? How do I enable this funtionality?

    Based on the link below, FortiGate can send an ICMP echo-request to the IP address before it provides the DHCPOFFER to the client. If FortiGate receives an ICMP echo-reply from the IP address, it will abandon that IP address, and then store the IP information as 'Removed due to conflict' in the GUI.

    https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-DHCP-status-Removed-due-to-conflict/ta-p/259956#:~:text=FortiGate%20can%20send%20an%20ICMP,to%20conflict'%20in%20the%20GUI

    Thank you!

    pminarik
    Staff
    pminarikAnswer
    Staff
    October 24, 2024

    As I noted already: I only saw conflict detection via ARP message. I didn't see an ICMP attempt. ARP should be a better option anyway - devices aren't obliged to respond to pings, but they absolutely have to respond to ARP, if they want to function within that subnet.

     

    (maybe there would be a follow-up ping if ARP succeeded, but the ARP request failing should be a sufficient sign of the IP being unused).

     

    edit: For the sake of the exercise, I've intentionally introduced a potential for conflict, and here's what happened:

     

    1, DHCP discover sent by client

    2, FGT ARP-requests for potential IP

    3, other device responds to ARP

    4, FGT pings the potential IP

    5, other device responds to ping

    => IP temporarily blacklisted

    6, DHCP discover re-sent by client

    7, FGT ARP-request for another potential IP

    8, no ARP reply

    9, FGT sends DHCP OFFER with this IP

    ...

     

    So yes, the FortiGate will ping for the IP to be assigned, provided that the conflicting device is capable of responding to ARP requests (which it very much SHOULD).

     

    The conflict appears to be cached for 30 minutes, based on the lease list output:

    > execute dhcp lease-list

     

    Hope it helps.

     
      Terms & ConditionsAccessibility statement