FortiOS 5.2.3 is out

[hklb]

.

[VicAndr · Accepted solution]

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

[Paul_S · Accepted solution]

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

[rwpatterson · Accepted solution]

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!

[FGTuser]

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]

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]

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.

[dfroe]

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]

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.

[Carl_Wallmark]

Does anyone have FSSO working with 5.2.3 ?

[storaid]

Selective wrote:

Does anyone have FSSO working with 5.2.3 ?

TEST MODEL: 200B-POE