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.
...discovered another bug with v.5.2.3. Administrators who are restricted to provision guest accounts only, can't actually print those accounts (to hand over login IDs and passwords to relevant users). In attempt to do so a FortiGate responds with "Error 500: Internal Server Error".
...didn't have this problem before the upgrade [&:].
hklb wrote:
Change your encoding in your browser (in chrome : option - more tools- encoding - western) and it works.
Support said the encoding error will be fixed in 5.2.4
FG200D 5.6.5 (HA) - primary [size="1"]FWF50B' s 4.3.x, FG60D's 5.2.x, FG60E's 5.4.x [Did my post help you? Please rate my post.][/size] FAZ-VM 5.6.5 | Fortimail 5.3.11 Network+, Security+
Also you cannot load the DNS screen.
When upgrading to 5.2.3, the admin accounts have changed from 'super_admin' to 'prof_admin'. We had the same issue here. We simply went into a backup, changed the admin types and restored the config. I did this remotely, hoping I wouldn't have to drive in. It worked flawlessly.
By the way, we got the answer from support. My guru is better than your guru!
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
@rpetty
Hi,
have you checked the "ALL" Service?
Firewall Service Protocol Number Change 2015-04-02 Subject: Firewall Service Protocol Number Change Released: 2015-04-02 Modified: 2015-04-02 Product: FortiGate
Description:
In FortiOS v5.0.8 and v5.0.9 and v5.2.0 through v5.2.2, the default value of the firewall service protocol number was changed from a value of 0 to 6.
The most commonly observed impact of this change is that after upgrading to the affected firmware, the “ALL” service matches only TCP traffic.
Executing a factory-reset on the FortiGate device does NOT change the default value to 6.
Affected Products:
All FortiGate models.
Resolution:
FortiOS v5.0.10 and v5.2.3 has fixed the issue. Upon upgrading the FortiGate device, the firewall service protocol number is restored to 0.
Workaround:
Those wishing not to upgrade the firmware can modify the affected firewall services to explicitly set the protocol-number to 0. For example:
config firewall service custom
edit "ALL"
set protocol-number 0
next
OndrejD wrote:I don't see any release notes in download dir or anywhere else.
Just checked, and release notes are in the download directory. Search for fortios-v5.2.3-release-notes.pdf.
First impressions after upgrading from 5.2.2 on a FortiGate 1000C with a few hundred policies and objects:
FortiView received some performance refinements and searching is more consistent throughout.
We had a few policies which used an SSL inspection object with "protect SSL server" enabled. These stopped working with 5.2.3 until I removed the SSL inspection object on them. I will properly investigate when time permits, but it's not a big issue for us now.
Log viewing has received a significant overhaul. Reverse DNS is showing up consistently for sources and search results will no longer randomly come up empty. I had to chuckle a bit, as I was praising the FortiOS platform to a potential adopter the other week, but had to voice some frustration about the so-so log viewer performance.
Still testing some of our web filtering policies that previously worked better with flow-based vs proxy and vice versa, but so far everything seems stable and consistent. Fingers crossed....
natech wrote:
We had a few policies which used an SSL inspection object with "protect SSL server" enabled. These stopped working with 5.2.3 until I removed the SSL inspection object on them. I will properly investigate when time permits, but it's not a big issue for us now.
Did you use flow-based or proxy-based SSL inspection? It mainly depends on which kind of AV you apply to that policy. Proxy-based SSL inspection will completely terminate the SSL session on the FG (resulting in different cipher suites towards the client) while flow-based does some kind of "don't touch, only look" and tries to decrypt the passing stream without modifying it.
With proxy-based SSL inspection there was a bug that the FG did not reply the complete certificate chain which broke everything with chained certificates. I was in contact with tech support and after several months they finally fixed it. Since 5.2.3 GA the proxy-based SSL inspection now also works with chained certificates.
So my first impression with 5.2.3 is that the "protect SSL server" is now working better than before.
I just hope that they didn't break anything else while fixing this issue.
At the moment I am only having some problems with "protect ssl server" and long idle (>5min) connections (like IMAP IDLE). But that's nothing new and still under investigation with tech support.
Maybe you can share your results when you were able to finish your investigations.
Besides that 5.2.3 fixed several tiny nasty bugs and makes a good impression after upgrading the first set of firewalls.
dfroe wrote:
Did you use flow-based or proxy-based SSL inspection? It mainly depends on which kind of AV you apply to that policy. Proxy-based SSL inspection will completely terminate the SSL session on the FG (resulting in different cipher suites towards the client) while flow-based does some kind of "don't touch, only look" and tries to decrypt the passing stream without modifying it.
With proxy-based SSL inspection there was a bug that the FG did not reply the complete certificate chain which broke everything with chained certificates. I was in contact with tech support and after several months they finally fixed it. Since 5.2.3 GA the proxy-based SSL inspection now also works with chained certificates.
So my first impression with 5.2.3 is that the "protect SSL server" is now working better than before.
I just hope that they didn't break anything else while fixing this issue.
At the moment I am only having some problems with "protect ssl server" and long idle (>5min) connections (like IMAP IDLE). But that's nothing new and still under investigation with tech support.
Maybe you can share your results when you were able to finish your investigations.
Besides that 5.2.3 fixed several tiny nasty bugs and makes a good impression after upgrading the first set of firewalls.
dfroe,
Did tech support help you with the connection with long idle times? I have a similar issue with Exchange active sync. Event logs tell me to make sure my firewall is not closing connections too soon: https://support.microsoft.com/en-us/kb/905013
Do you have a bug ID for the SSL chain issue? that may be affecting me.
FG200D 5.6.5 (HA) - primary [size="1"]FWF50B' s 4.3.x, FG60D's 5.2.x, FG60E's 5.4.x [Did my post help you? Please rate my post.][/size] FAZ-VM 5.6.5 | Fortimail 5.3.11 Network+, Security+
Paul S wrote:dfroe wrote:Did tech support help you with the connection with long idle times? I have a similar issue with Exchange active sync. Event logs tell me to make sure my firewall is not closing connections too soon: https://support.microsoft.com/en-us/kb/905013
[...]At the moment I am only having some problems with "protect ssl server" and long idle (>5min) connections (like IMAP IDLE). But that's nothing new and still under investigation with tech support.
Sorry that I forgot to post my results.
That issue had been tracked with ticket number 1346577.
L2 engineering figured out that it actually is a IPS timeout which is killing the session.
The IPS engine has a hard coded 5 minutes idle timeout!
According to TAC this is function as designed so they did not open a bug id and cinstead losed my ticket suggesting that I should have to create a feature request for that.
In my opinion this is clearly a bug; but well, opinions differ..
As soon as the IPS engine kicks it, it gives a ... on the regular session timeouts. So regardless of what session-ttl you configure, the IPS always kills the session as soon as a new packet is transmitted after the connection had been idle for more than 5 minutes.
With diag sys session you can verify that the session has a long timeout and is far away from expiring.
But a diag ips debug will show you this error after 5 minutes: ips_run_session_verdict_check: can't find session
Then the FG sends a TCP reset, kills the session, and as a result the session also disappears under diag sys session.
So with applications like IMAP idle, ActiveSync push mail, etc. this is a real show stopper.
Since the IPS engine has a hard coded timeout ignoring the usual session-ttls, we would need the possibility to tweak that IPS timeout at least for certain services or policies.
My suggestion would be a new option like ips-ttl which defaults to 600 (5min.) but being configurable to whatever we need. This way we would extend the timeout for IMAP idle, ActiveSync etc.
So far I had no success to get this bug or feature request beeing addressed by my technical sales representative. Maybe you have more luck...
Paul S wrote:That was ticket# 1214742 and bug# 0250516 (finally fixed in 5.2.3).Do you have a bug ID for the SSL chain issue? that may be affecting me.
Yesterday I upgraded an FG-80C (1 G) from 5.0.11 first to 5.2.2 and then to 5.2.3 (as I didn't know of the new release in the morning).
On both occasions, the FGT behaved way too slow after the reboot. The GUI was sluggish and really a pain. Operation though was fine, except for the "custom service" in 5.2.2 which was wrong (this has been on the forums quite often now).
Additionally, the FortiGuard status was wrong: hardware 'licensed' but AV and IPS 'not registered' which clearly was wrong. An inspection with 'get sys fortiguard-service status' showed an AV engine version '1.000', the log was full of messages 'FortiGuard servers unreachable' and an 'exec update-now' produced 'error 6'.
I ran a 'exec formatlogdisk' with a reboot and after that everything worked fine.
After 'exec update-now' the engine and signatures were up-to-date.
This was repeated after the upgrade from 5.2.2 to 5.2.3. 'exec formatlogdisk', reboot and Bliss!
The update to 5.2.3 corrected several minor config errors, such as
firewall services custom
'set tcp-portrange 0' is replaced by 'unset tcp-portrange' in services
ALL, ALL_UDP, DHCP, IKE, QUAKE, RAUDIO, RIP, SIP, SYSLOG, TALK, TFTP, MGCP, DHCP6, RADIUS, RADIUS-OLD, TRACEROUTE, LDAP_UDP, NetBios-NS, NetBios-DS
in 'ALL_CUSTOM', 'set protocol-number 6' was added
in 'NONE', 'set tcp-portrange 0' was added.
So for admins still running 5.2.2 and having upgraded from 5.0.x you should have a look at these service definitions.
One last observation:
I had a static route defined for a dial-in IPsec VPN. The upgrade to 5.2.3 removed it rightfully as the dial-in VPN will create a dynamic route entry according to the (dynamic) proxy addresses.
Does anyone have FSSO working with 5.2.3 ?
FCNSA, FCNSP
---
FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30B
FortiAnalyzer 100B, 100C
FortiMail 100,100C
FortiManager VM
FortiAuthenticator VM
FortiToken
FortiAP 220B/221B, 11C
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 |
---|---|
1634 | |
1063 | |
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.