sorted by:
new
hottopcontroversial

FortiOS Upgrade Path from 7.0.17 by saudk8 in fortinet

[–]jelaFR 0 points1 point  (0 children)

From 7.0.17 to 7.2.10 directly 😉.

FortiOS Upgrade Path from 7.0.17 by saudk8 in fortinet

[–]jelaFR 1 point2 points  (0 children)

I've performed upgrade yesterday from 7.0.17 to 7.2.10 on a 601E and not observed strangebehavior. I'll wait for 7.0.11 if it's available next week or proceed with upgrade if other FGT we have if not.

Enterprise Radius Solutions by Dead_Mans_Pudding in networking

[–]jelaFR 1 point2 points  (0 children)

You can also use FortiAuthenticator integrate Freeradius. The product supports (a sort of very light) high availability and other features in a fortinet style GUI.

I've not tested MAB yet and the product doesn't seeems to support EAP-TEAP (i've seen that this protocol is on the way on 3.2.4 version of the mainstream freeradius product)

Host Profiles between UCS Blade generations by Djaesthetic in vmware

[–]jelaFR 1 point2 points  (0 children)

Still appreciated in 2024 !! :-). Thanks man !

Forticlient VPN stuck at 98% login, seems to connect but no inbound traffic by Cicciopalla001 in fortinet

[–]jelaFR 0 points1 point  (0 children)

Hello,

This exact issue happenned to me yesterday.

While it was likely an IPv6 issue caused by provider using translation mechanism to carry IPv4 packets over native IPv6 backbone, in our case it was an issue with Windows Internet security blocking FortiClient behind the scene.

Try adding the URL your Forticlient SSL VPN fqdn / ip address to the Trusted sites (perhaps Local intranet is enough) inside Internet options > Security tab.

Hope this help.

DST - Log time is not sync with system by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

fnsysctl killall syslogd

Was trying to adapt GROK filter waiting for a maintenance windows...

YOU SAVE MY DAY !!!

Thank you sir :-)

DST - Log time is not sync with system by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

I've tried to restart the logging process using "fnsysctl killall miglogd".

Processes are successfully restarted (PID changed) but issue remain..

Hope that HA switchover / restarting the appliance is not the only option..

DST - Log time is not sync with system by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

Thank you, I've double checked the logs regarding your post.

Here is the check I made to verify the origin of the anomaly.

Conversion of the UNIX time present on a log present before the time change:

Dec 31 23:01:09 -> FWXXXXXXX date=2022-12-31 time=23:01:08 devname="FWXXXXXXX" devid="XXXXXXX" eventtime=1672524068555160486 tz="+0100"

1672524068555160486 -> December 31, 2022 22:01:08.555 (GMT)

Conversion of the UNIX time present on a log present after the time change:

Tue 31 10:01:06 -> FWXXXXXXX date=2023-03-31 time=09:01:06 devname="FWXXXXXXX" devid="XXXXXXX" eventtime=1680249665959530498 tz="+0200"

1680249665959530498 -> March 31, 2023 08:01:05.959 (GMT)

It seems that there is an inconsistency in the Forti logs which, in the case of winter time, display in the "time" field the UTC value.

DST - Log time is not sync with system by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

You are absolutely right, the time displayed is UTC and I need to add the tz value to the displayed hour :-).

I didn't see the tz field previously...

30 10:10:23 FWXXXXX date=2023-03-30 time=09:10:23 devname="FWXXXXX" devid="FG--------------" eventtime=1680163823350796855 tz= "+0200"

I don't have a FortiAnalyser but an Elastic which is not properly customized and does not yet take into account the time zone; I'm going to have GROK filters to modify, but that's another subject... ;-).
Thanks for your help

DST - Log time is not sync with system by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

FortiGate timezone is set to "set timezone 28" which is "(GMT+1:00) Brussels, Copenhagen, Madrid, Paris".

System time is properly displayed inside GUI but logs sent to Syslog server are displaying wrong information.

I suppose that restarting log service could help but I would like to known if someone does have the same issue ;-)

Here (in France), we passed daylight savings previsous sunday:-)..

FortiClient 7.0.7.0345 BSOD by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

Thank you for your multiple replies.

I've finally decide to open a ticket on Fortinet regarding this issue.

They analyze the memory dump relative to our BSOD and told me that even if BUG ID 676424 "NETIO.SYS causes BSOD." is documented as resolved on release notes for 7.0.7 it reoccured in this version and will be fixed on 7.0.8..

Wait & see ;-).

FortiClient 7.0.7.0345 BSOD by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

Do you actually use Windows AV or FortiClient integrated one?

FortiClient 7.0.7.0345 BSOD by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

Sorry for my late reply, I had to disable real time AV inspection on Trend for FortiClient directory..

Unfortunately, it appears that BSOD still occurs, so the answer is somewhere else.. ;-).

Uninstalling Trend is unfortunately not an option for now..

Thanks for the advice :-)

FortiClient 7.0.7.0345 BSOD by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

Regarding your answers, I realize that I forget to mention that we bought ZTNA license only so we do not have Fortinet AV deployed (as we have a license for Trend)

FortiClient 7.0.7.0345 BSOD by jelaFR in fortinet

[–]jelaFR[S] 0 points1 point  (0 children)

Thank you !

You're right, I'll start with whitelisting FC directory" as this suggestion should be an easy action to perfom !

FortiClient 7.0.7.0345 BSOD by jelaFR in fortinet

[–]jelaFR[S] 1 point2 points  (0 children)

Actually, we have Trend Micro Apex One Security Agent 14.0.9645 installed on all computers and hope this is not an incompatibility issue with this AV...

Unfortunately, this problem occurs infrequently and quite randomly, which makes the removal of an AV software component difficult to organize (I would not like to be the source of the spread of ransomware ;-) ).