Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
hklb
Contributor II

FortiOS 5.2.3 is out

.

4 Solutions
VicAndr
New Contributor III

...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 [&:].

View solution in original post

Paul_S

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+

View solution in original post

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+
rwpatterson
Valued Contributor III

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

View solution in original post

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
TheJaeene
Contributor

@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

 

View solution in original post

56 REPLIES 56
FGTuser
New Contributor III

I don't see any release notes in download dir or anywhere else.

Jeroen

OndrejD wrote:

I don't see any release notes in download dir or anywhere else.

http://docs.fortinet.com/d/fortigate-whats-new-for-5.2

natech
New Contributor

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....

dfroe
New Contributor

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.

Paul_S

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+

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+
dfroe
New Contributor

Paul S wrote:

dfroe wrote:
[...]

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.

 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

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:

Do you have a bug ID for the SSL chain issue? that may be affecting me.

That was ticket# 1214742 and bug# 0250516 (finally fixed in 5.2.3).

ede_pfau
SuperUser
SuperUser

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.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Carl_Wallmark
Valued Contributor

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

FCNSA, FCNSP---FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30BFortiAnalyzer 100B, 100CFortiMail 100,100CFortiManager VMFortiAuthenticator VMFortiTokenFortiAP 220B/221B, 11C
storaid

Selective wrote:

Does anyone have FSSO working with 5.2.3 ?

TEST MODEL: 200B-POE

 

 

FWF60D x2 FWF60C x3 FGT80C rev.2 FGT200B-POE FAP220B x3 FAP221B x2

FSW224B x1

FWF60D x2 FWF60C x3 FGT80C rev.2 FGT200B-POE FAP220B x3 FAP221B x2 FSW224B x1
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors