Many Bugfixes but no TLS 1.3 mentioned.
https://docs.fortinet.com.../fortios-release-notes
sudo apt-get-rekt
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.
Ich verstehen Sie, aber meine Deutsch ist sehr schlecht!
So I just got off the phone with the TAC. Did lots of testing. We thought the issue was with our FAZ, but after doing some more checking we decided to check the miglogd process.
If you log into the CLI
diag sys top-summary
look for the miglogd process and note the process ID (PID)
[style="background-color: #ffff00;"]197 [/style] 320M 0.0 2.0 73 09:19.30 miglogd [x5]
Press "q" to quit the monitoring of sys top.
Now that you have the PID of the miglogd process, enter the following to kill and restart it:
dig sys kill 11 197
Note in my case the PID was 197 as highlighted above. Once we did this, we saw this in the crashlog:
diag debug crashlog read
509: 2019-06-05 13:36:40 <00197> application miglogd 510: 2019-06-05 13:36:40 <00197> *** signal 11 (Segmentation fault) received *** 511: 2019-06-05 13:36:40 <00197> Register dump: 512: 2019-06-05 13:36:40 <00197> RAX: fffffffffffffffc RBX: 0000000000ed19e0 513: 2019-06-05 13:36:40 <00197> RCX: ffffffffffffffff RDX: 0000000000000400 514: 2019-06-05 13:36:40 <00197> R08: 0000000000000000 R09: 0000000000000008 515: 2019-06-05 13:36:40 <00197> R10: 00000000000006d6 R11: 0000000000000246 516: 2019-06-05 13:36:40 <00197> R12: 00007fff4adca950 R13: 0000000000000000 517: 2019-06-05 13:36:40 <00197> R14: 00007fff4adca950 R15: 0000000015477b10 518: 2019-06-05 13:36:40 <00197> RSI: 00000000151a9550 RDI: 000000000000000a 519: 2019-06-05 13:36:40 <00197> RBP: 00007fff4adca5f0 RSP: 00007fff4adca5b8 520: 2019-06-05 13:36:40 <00197> RIP: 00007f1ff42bbba0 EFLAGS: 0000000000000246 521: 2019-06-05 13:36:40 <00197> CS: 0033 FS: 0000 GS: 0000 522: 2019-06-05 13:36:40 <00197> Trap: 0000000000000000 Error: 0000000000000000 523: 2019-06-05 13:36:40 <00197> OldMask: 0000000000000000 524: 2019-06-05 13:36:40 <00197> CR2: 0000000000000000 525: 2019-06-05 13:36:40 <00197> stack: 0x7fff4adca5b8 - 0x7fff4adcb800 526: 2019-06-05 13:36:40 <00197> Backtrace: [size="1"]527: 2019-06-05 13:36:40 <00197> [0x7f1ff42bbba0] => /usr/lib/x86_64-linux-gnu/libc.so.6[/size] 528: 2019-06-05 13:36:40 (epoll_pwait+0x00000020) liboffset 000f4ba0 [size="1"]529: 2019-06-05 13:36:40 <00197> [0x01dfb8d1] => /bin/miglogd[/size] [size="1"]530: 2019-06-05 13:36:40 <00197> [0x00ed25fa] => /bin/miglogd[/size] [size="1"]531: 2019-06-05 13:36:40 <00197> [0x0042ea44] => /bin/miglogd[/size] [size="1"]532: 2019-06-05 13:36:40 <00197> [0x0043529f] => /bin/miglogd[/size] [size="1"]533: 2019-06-05 13:36:40 <00197> [0x004321e8] => /bin/miglogd[/size] [size="1"]534: 2019-06-05 13:36:40 <00197> [0x004326de] => /bin/miglogd[/size] [size="1"]535: 2019-06-05 13:36:40 <00197> [0x00434584] => /bin/miglogd[/size] [size="1"]536: 2019-06-05 13:36:40 <00197> [0x00434ee7] => /bin/miglogd[/size] [size="1"]537: 2019-06-05 13:36:40 <00197> [0x7f1ff41e7eaa] => /usr/lib/x86_64-linux-gnu/libc.so.6[/size] 538: 2019-06-05 13:36:40 (__libc_start_main+0x000000ea) liboffset 00020eaa [size="1"]539: 2019-06-05 13:36:40 <00197> [0x0042b7da] => /bin/miglogd[/size] 540: 2019-06-05 13:38:40 the killed daemon is /bin/miglogd: status=0x0 Crash log interval is 3600 seconds miglogd crashed 1 times. The last crash was at 2019-06-05 13:36:40
After that DNS records started flowing and populating in FAZ again! We are not sure of the cause or how to replicate. But it appears to be resolved. We will monitor to see if the logs keep flowing as they should now.
Does it has WFQ and WRED?
WFQ and WRED?
sudo apt-get-rekt
Is anyone else slightly concerned about the number of bug fixes in this release - despite it being the fifth point release on 6.0.x. This erodes confidence somewhat when you have nearly thirty fixes in the SSL VPN module alone.
I actually had a FTNT account manager in a previous role tell me not to touch code for production until the fourth point release but maybe we are looking at the fifth now? Less releases but sounder code would be my preference - or maybe I am being naive.
I would agree with the account manager. I have been using Fortigate since version 2.8 and it always took to patch 4 or 5 to become stable enough for production use. Heck v5.2 took to patch 8.
-DDSkier FCNSA, FCNSP FortiGate 400D, (2) 200D, (12) 100D, (2) 60D
Looks promising. Two gotchas to be aware of for those upgrading:
473075
When upgrading, multicast policies are lost when there is a zone member as interface.
481408
When upgrading from 5.6.3 to 6.0.0, the IPv6 policy is lost if there is SD-WAN member as interface.
With regard to the question about 'stable' releases, in my experience the answer is, it depends. I've rolled out a 600+ 60D deployment that we piloted on 5.2.0 and went into production on 5.2.1 with no issues whatsoever, it all depends on your use case. If you're not going to use ssl vpn then a buggy ssl vpn is irrelevant to you.
Depending on the scenario and potential risks of upgrading to a new MR later on, I would much prefer to roll out an earlier version of a major release, after testing, with a view that it will stay on that MR for several years.
streeb2021 wrote:Is anyone else slightly concerned about the number of bug fixes in this release - despite it being the fifth point release on 6.0.x. This erodes confidence somewhat when you have nearly thirty fixes in the SSL VPN module alone.
I actually had a FTNT account manager in a previous role tell me not to touch code for production until the fourth point release but maybe we are looking at the fifth now? Less releases but sounder code would be my preference - or maybe I am being naive.
I totally agree that more recent releases seem to contain more known issues than fixes which is disconcerting. You are absolutely right to wait until at least .3 or .4 and to TEST with backups! My experience; YMMV, is that I have a FWF-60E at home. 6.0.4 caused it to lose DNS for some reason and only resolution I could find was to migrate back to 6.0.3 and it has been stable ever since. BUT this is a very low traffic device NOT doing SSL inspection NOR VPN. Only basic Firewall tasks with one FSW-108D-POE and FortiAP-221C.
At work we just deployed 501Es in Active/Passive mode with DPI and ~100 policies. We took a config from 5.6.8 on a 500D and upgraded it to 6.0.3 on the 501Es. NOT A TASK FOR THE FAINT OF HEART. But we have lots of CLI experience and have done so in the past. It has been running very well with two issues.
For whatever reason, Chrome does not like to display screens with lists such as policies, addresses, or logs in our instance of 6.0.3. Kind of an issue! The workaround for us is to use Firefox and that works fine.
The other issue is we have a legacy app that requires IE11. If a user is using the SSLVPN Portal and a RDP connection, clicking on an IE11 tab will kill the session. A VERY ODD issue, but TAC indicates a known problem.
I found an internal ticket referencing this issue (Mantis #0519121). As confirmed by our DEV/QA SSLVPN web mode does not support/handle IE very well on 6.0 FortiOS. This is something that will improve and get fixed in future patches.
It does not appear to be fixed in 6.0.5. So other than these two issues, two 501Es in HA with 6.0.3 has been very stable. We have approximately 300 users accessing a 1G connection with lots of filters and controls enabled. We also have lots of users using VPN.
I think too few folks consider the horsepower of their unit when considering updates. The bigger firewalls with D or E chips will run better than a smaller D. Use the feature selection gui and disable things like Wifi and Switch control if you are not using them. It is frustrating but sometimes you just have to sit back and wait for a later, more stable release than what is currently available. I'd love to try 6.2 but I'm not touching it until .4 or .5 comes out. Release notes and these forums will indicate when the time is right.
Hi Seadave, thank you for your constructive feedbacks. >For whatever reason, Chrome does not like to display screens with lists such as policies, addresses, or logs in our instance of 6.0.3. Kind of an issue! The workaround for us is to use Firefox and that works fine. Yes, this is a known issue in 6.0.3 (M0527700) and we already fixed it in 6.0.4
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 |
---|---|
1631 | |
1063 | |
749 | |
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.