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!

[Jaymo]

DJensen99 we had a very similar issue, our was that our wifi clients would get a ip but not go anywhere? so i looked in the analyzer/logs and saw that all dns traffic was now being blocked even thought for that subnet had open access rule to the net. So i created a new policy and placed it in the top spot that allowed the entire subnet in question for only the dns service and that fixed everything.  

[NeilG]

On a new 60D with upgraded to 5.2.3 I have noticed an odd DHCP reservation issue that can cause 100% CPU utilization.

Sequence:

Configure the 60D for interface mode instead of switch.

On InterfaceX (5 in my case) configure the interface and enable the DHCP for that interface.

Now bring up a windows 7 or windows 8 device to get a DHCP lease, example in this case was 192.168.115.2/255.255.255.0

From the Monitor->DHCP select the windows device and reserve a different address of 192.168.115.41

Most of the time the gui will proceed but it will look like nothing happened. Refreshing the DHCP monitor show the windows device at 192.168.115.2 still (which makes sense as the client has not released the reservation)

Now reboot the windows device.

The Windows device will fail to negotiate a DHCP assigned address and the fortigate will go to 100% CPU.

Solution:

A new web management session is possible but will take a very long time to come up.

Navigate the to DHCP Monitor and delete the current 192.168.115.2 lease. You will now in the GUI see the reserved 192.168.115.41

Disable/Enable the Windows Ethernet adapter.

CPU will drop down from 100% and the windows client will get the correct 192.168.115.41 address.

(Note- I had 4 of these and CPU didn't return to normal until all non-reserved addresses had been deleted.)

I hope this info helps someone else.

-N

[jodros]

I am thinking of upgrading our 3600's in a HA cluster from 5.0.9 to 5.2.3.  It appears that there have been a few features added as well as improvements to configuration tasks.  Thoughts?

[SecurityPlus]

Upgraded a FortiWiFi 60D earlier today from 5.2.2 to 5.2.3 and it seems to be running well.

[SteveRoadWarrior]

Running two new 92D on 5.2.3

Firewalling, BGP, routing work well.  Really love the new logging/drilldowns.

DHCP server has the issue where it won't work properly through a software switch, but this is known to the forums.

Also having a devil of a time getting these two matched Fortigates to VPN tunnel up.  Trying all available settings.  They'll negotiate one side (inbound/outbound) but not the other, using cut/paste and side by side comparison.  Got further by using IKEv1 and not IKEv2, but yikes this is a real issue.  FYI, this is not our first rodeo.  I do a lot of VPN's... routing, policy are all set with values which work under 5.0.  Can't even ping to the other side of the tunnel (with a /30 added to the static route table).

I can get the tunnels now to say tunnel_up in the logs/IPSEC Monitor, but am only getting traffic flow in one direction.  Given my age, I'm not a fan of One Direction.

-Steve

[Paul_S]

SteveRoadWarrior wrote:

Running two new 92D on 5.2.3

Firewalling, BGP, routing work well.  Really love the new logging/drilldowns.

DHCP server has the issue where it won't work properly through a software switch, but this is known to the forums.

Also having a devil of a time getting these two matched Fortigates to VPN tunnel up.  Trying all available settings.  They'll negotiate one side (inbound/outbound) but not the other, using cut/paste and side by side comparison.  Got further by using IKEv1 and not IKEv2, but yikes this is a real issue.  FYI, this is not our first rodeo.  I do a lot of VPN's... routing, policy are all set with values which work under 5.0.  Can't even ping to the other side of the tunnel (with a /30 added to the static route table).

I can get the tunnels now to say tunnel_up in the logs/IPSEC Monitor, but am only getting traffic flow in one direction.  Given my age, I'm not a fan of One Direction.

-Steve

you should post a new thread about your VPN troubles and then link to it here. Post some of your config from the CLI and maybe we can help.

[FGTuser]

SteveRoadWarrior wrote:

I can get the tunnels now to say tunnel_up in the logs/IPSEC Monitor, but am only getting traffic flow in one direction.  Given my age, I'm not a fan of One Direction.

Did you try to set npu-offload disable in phase1?

Maybe it's not the case here, but might help.

[DJensen99]

SteveRoadWarrior wrote:

DHCP server has the issue where it won't work properly through a software switch, but this is known to the forums.

So that's the DHCP issue in 5.2.3?  I never thought of looking at the software switch, but that's exactly where DHCP had issues in our environment in 5.2.3.

[SteveRoadWarrior]

Just a follow up to let others know what VPN settings worked for me:

Phase I

Remote Gateway: Static address (didn't try any other settings)

Preshared Key (didn't try with cert)

Mode Config: OFF (this didn't work when set to on)

NATT: currently OFF (didn't see a difference)

Dead Peer Detect: On (seemed to hang for a long time if not enabled)

Authentication: IKEv1 (IKEv2 doesn't seem to work), Mode: Agressive, Any Peer ID

Phase I Proposal: AES128-SHA256  DH 14

Phase II

Local: Subnet (0.0.0.0/0.0.0.0)

Remote: Subnet (0.0.0.0/0.0.0.0)

Enco: AES128-SHA256

Replay Detect: off

PFS: off

Local port: all

Remote port: all

Protocol: all

AutoKey Keep Alive: Off

AutoNegotiate: Off

Also look earlier in this thread for disabling the acceleration in phase I.

I know these aren't nearly the safest settings.  When the firmware comes out to fix this, I'll tighten it up.

This VPN has to be manually enabled and is used as a failover for a leased line.

Hopefully, this will give someone else a good starting point.

[Paul_S]

I just upgraded 5.2.2 > 5.2.3. I am on the phone with support now.

config firewall vip bug stopped by SSL inspection/protection of my server to stop working. Firefox showed a unexpected cipher change errror.

known bug according to support. fixed in 5.2.4. the work around is

config firewall vip

edit virtual_server_name

set ssl-client-session-state-type disable

next

end

not listed in known issue on release notes, so it must have been found after GA of 5.2.3