FortiOS 5.2.3 is out

another problem.

upgraded fortigate 110c from 5.2.2 to 5.2.3

wifi controller->managed fortiaps doesn't show any aps (total of 30), thinking an thinking minutes...sometime (1 of 30 times) shows aps normally....aps wifis are working correctly.

thanks

The problem I saw is src-vis process, always running 15-30%, is it normal?, thanks

Just had to roll back a handful of 60Ds from 5.2.3 to 5.2.2.  Most iDevices and a handful of other random devices would no longer reliably obtain a DHCP address on WAPs wired directly to the units.  I tried reversing the DHCP service definitions mentioned further up the thread with no effect.  I couldn't duplicate the issue with any equipment that I have.

The units showed a valid IP assigned to the units, but the affected devices all showed as APIPA.  After rolling back the firmware, only a handful of iDevices are having issues, probably related to the bugs in IOS8.  No other issues noted with the new firmware.

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.  

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

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?

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

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

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.

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