Hi Everyone,
I have a unique and frustrating situation with an ISP that can only provide service via DHCP - and that DHCP is provided by another 3rd party as their last mile provider who refuses to acknowledge their mistake because "it still works for others"
I have a remote site fortigate that loses it's WAN DHCP lease every other day or so because the upstream relay is providing an unreachable internal IP (10.x.y.z) as the server and relay IP in the original DHCP lease. I have packet captures of this and watching the fortigate constantly trying to renew the lease with direct IP packets to this address, obviously being dropped by the next hop. It's only when the fortigate loses its lease completely and finally falls back to broadcast discovery / requests that its able to recover.
Question: is it at all possible to configure the DHCP Client on the fortigate to do "broadcast requests" for leases exclusively, without trying to renew via unicast?
I know this is not the standard and where the responsibility really lies for this to be resolved, but a workaround like this would really help right about now. It's been a month of broken telephone and ignorant responses from the 3rd party last mile provider.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
That is a frustrating situation. Most probably that it's not possible since this is something inherited from the protocol itself.
What you can do as a workaround is try to create an automation Stitch with a CLI script and schedule it to make the renewal early in the morning. I can't test it right now but I guess this will start a new broadcast process for the discovery.
If this will still use unicast for IP renewal you can use a similar script to turn down/up the WAN interface:
config system interface
edit "port1"
set status down > up
Hello 80211WiGuy,
Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.
Thanks,
That is a frustrating situation. Most probably that it's not possible since this is something inherited from the protocol itself.
What you can do as a workaround is try to create an automation Stitch with a CLI script and schedule it to make the renewal early in the morning. I can't test it right now but I guess this will start a new broadcast process for the discovery.
If this will still use unicast for IP renewal you can use a similar script to turn down/up the WAN interface:
config system interface
edit "port1"
set status down > up
Thank you Emirjon, thats a great idea! I'm going to test it out this week. I've just created a trigger for 3:30am to do a wan1 down, wait 5s, wan1 up.
Just following up here, I've let it run overnight with packet captures and I believe it solves the issue! WAN interface is cycling before it gets stuck in the persistent unicast based renewal loop and able to obtain a new lease via broadcast. It's set for an early morning time so it doesnt have any major negative impact on operations. Not perfect, but much better than having the internet go down in the middle of web conferencing. Thank you for the excellent idea Emirjon!
Thank you for your feedback, glad to help.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1641 | |
1069 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.