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
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
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.
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+
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.
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.
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
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+
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 |
---|---|
1536 | |
1029 | |
749 | |
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.