60E on 6.0.4. I am using the FGT as DHCP server. The FGT itself has timezone and offset (-5 hours Eastern) and reflects the correct time in the dashboard. The DHCP server on the FGT is defined with "set timezone-option specify" and "set timezone 12" where "12" corresponds to -5 Eastern per "set timezone ?".
The problem is, the FGT DHCP server is sending out option 2 time offset of -14400s which is -4 hours. I've confirmed this with a packet capture made on the FGT and viewed in WireShark. It should be sending -18000s or -5 hours.
If I set the DHCP server to "set timezone-option default" I still have the same problem, the time offset is still -4
Anyone seen this issue before?
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.
I've been back and forth with Fortinet support on this. It's been definitely determined that when a FGT DHCP Server Time Zone option is set to a time zone that observes DST, the DHCP Server will send the time zone offset adjusted for DST in DHCP Option 2. Fortinet support's stance at the moment is that this is "correct" and to "turn off DST handling on your client device"
I'm trying to get support to understand that this is not the industry standard on how DST offsets are handled. DST offset is intended to be handled by the client device, not server side, and they should always send a time zone offset based on standard time.
I've also explained that there is no way to properly set DHCP Option 2 myself and override their behavior. You can't do it in the GUI whatsoever. You can do it in the CLI but if you ever try to modify the Interface settings in the GUI it will not let you save until you delete the DHCP Option 2 parameter.
As of now, the only way to make sure any devices that is picking up DHCP Option 2 in order to calculate it's time offset is to turn off DST handling on the device or set the time zone on the DHCP server to be 1 hour slower during DST calendar period (ie. if you are in eastern time, choose central time as the time zone when we are in DST).
just an idea...some DHCP options have to be specified in hex. If you enter "12" is would mean 12hex = 18dec. But I haven't checked this.
Another idea: do you have DST enabled?
ede_pfau wrote:just an idea...some DHCP options have to be specified in hex. If you enter "12" is would mean 12hex = 18dec. But I haven't checked this.
DHCP option 2 is controlled by the DHCP advanced option of "Time Zone" in the GUI, which lets you choose "Same as System" or "Specify". When you use "Same as System" you end up in the CLI with "set timezone-option default" with nothing showing for "set timezone". If you use "Specify" than you have in the CLI "set timezone-option specify" and "set timezone 12" (in my case since I am choosing Eastern in the GUI)
The "12" is just some translation FortiOS is using internally. It seems like there is something going on as it relates to that translation and DST.
You actually can't manually specify DHCP Option 2 as a custom option. It tells you "Option is in use as DHCP setting: timezone-option, timezone" which is being setup by the option GUI setting. If I could set option 2 this way, I could makes sure the correct value is being sent,
Another idea: do you have DST enabled?
DST is enabled by default. I confirmed this by doing "set dst enable" under "config system global" but it doesn't display an entry under "show system global", indicating that is the default.
I've been back and forth with Fortinet support on this. It's been definitely determined that when a FGT DHCP Server Time Zone option is set to a time zone that observes DST, the DHCP Server will send the time zone offset adjusted for DST in DHCP Option 2. Fortinet support's stance at the moment is that this is "correct" and to "turn off DST handling on your client device"
I'm trying to get support to understand that this is not the industry standard on how DST offsets are handled. DST offset is intended to be handled by the client device, not server side, and they should always send a time zone offset based on standard time.
I've also explained that there is no way to properly set DHCP Option 2 myself and override their behavior. You can't do it in the GUI whatsoever. You can do it in the CLI but if you ever try to modify the Interface settings in the GUI it will not let you save until you delete the DHCP Option 2 parameter.
As of now, the only way to make sure any devices that is picking up DHCP Option 2 in order to calculate it's time offset is to turn off DST handling on the device or set the time zone on the DHCP server to be 1 hour slower during DST calendar period (ie. if you are in eastern time, choose central time as the time zone when we are in DST).
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 |
---|---|
1731 | |
1099 | |
752 | |
447 | |
240 |
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.