CAPWAP issue resolved - hurrah
No 80f 200f - boooo
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.
YEAH :)
Fortigate 60E v7.x (GA)
Upgraded a 60F from 6.4.3 to 6.4.4. So far no issues found.
When we upgraded to 6.4.3 we had the wireless issue and had to wtp-profile, edit "FortiAP-profile-name", set dtls-policy dtls-enabled to get traffic to pass. This hurt wireless speed but allowed it to pass traffic.
After upgrading to 6.4.4 we ran config wireless-controller wtp-profile, edit "FortiAP-profile-name", unset dtls-policy
This gave us good performance again.
Is it just me or is there an issue with 6.4.3 and 6.4.4 in regards to marking a wireless access point as Rogue. When I
try to mark an Unclassified AP ("?" Icon) as a Rogue AP or Suppressed Rogue AP via the GUI and click Apply, it says "Failed to save changes".
It's Probably not just you, I've had this exact problem for probably 6 months now, Fails to save changes.
Yes, among other things, these were reasons why my config made you completely from scratch after 10 years and many upgrades. I no longer have the issue of memory problems or save Rogue AP here. For this you can no longer connect to 5Ghz after about 1-2 days. Only a reboot of the AP's helps.
Fortigate 60E v7.x (GA)
Any major show stoppers in 6.4.4?
Not that I have seen.
We're seeing issues with the syslog delivered UTM logs in version 6.4.4. All our "vm64 AWS" instances that we upgraded to 6.4.3 are logging UTM events fine through syslog. All the 6.4.4 machines are missing UTM data for us to identify what the root cause is. Both resulted in a blocked request. (See logs at the bottom.)
We tried an EICAR file download test and the file was blocked but there was nothing in the syslog to specifically identify it as an EICAR event.
Our configs are almost identical between the 6.4.3 and 6.4.4 machines (except for local variances for networks).
We opened a case with support but are asking to see if people are experiencing the same issue?
Version 6.4.4 was only available to us in the last week or so.
Both hosts share the same config blocks:
(Syslog config) config log syslogd setting set status enable set server "10.224.0.89" set mode udp set port 514 set facility local4 set source-ip '' set format default set priority default set max-log-rate 0 set interface-select-method auto end (Policy config)
edit 1 set status enable set name "allow" set uuid d007ffd4-6f31-51e8-00f8-20af0b5a45de set srcintf "port1" set dstintf "port1" set srcaddr "INTERNAL" set dstaddr "all" set internet-service disable set internet-service-src disable unset reputation-minimum set rtp-nat disable set action accept set schedule "always" set schedule-timeout disable set service "ALL" set tos-mask 0x00 set anti-replay enable set utm-status enable set inspection-mode flow set profile-type single set profile-protocol-options "TN-Proxy" set ssl-ssh-profile "TN-certificate-inspection" set av-profile "TN-Virus" set webfilter-profile "TN-Web" set dnsfilter-profile 'TN-DNS' set emailfilter-profile 'TN-Email' set dlp-sensor 'TN-DLP' set file-filter-profile 'TN-File' set ips-sensor "TN-IPS" set application-list "TN-App" set voip-profile '' set logtraffic utm set logtraffic-start disable set capture-packet disable set auto-asic-offload enable set permit-any-host disable set permit-stun-host disable set fixedport disable set ippool disable set session-ttl 0 set vlan-cos-fwd 255 set vlan-cos-rev 255 set wccp disable set disclaimer disable set email-collect disable set natip 0.0.0.0 0.0.0.0 set diffserv-forward disable set diffserv-reverse disable set tcp-mss-sender 0 set tcp-mss-receiver 0 set comments '' set block-notification disable set replacemsg-override-group '' set srcaddr-negate disable set dstaddr-negate disable set service-negate disable set timeout-send-rst disable set captive-portal-exempt disable set dsri disable set radius-mac-auth-bypass disable set delay-tcp-npu-session disable unset vlan-filter set traffic-shaper '' set traffic-shaper-reverse '' set per-ip-shaper '' set nat enable next
Logs:
================================== Log for 6.4.4 pulling down an EICAR file via curl: Dec 22 13:37:55 FORTIGATE date=2020-12-22 time=13:37:54 devname="FORTIGATE-6.4.4" devid="XXXXXXXXXXXXXXX" eventtime=1608673075356948804 tz="-0800" logid="0000000013" type="traffic" subtype="forward" level="notice" vd="root" srcip=10.XXX.XXX.173 srcport=50968 srcintf="port1" srcintfrole="undefined" dstip=73.XXX.XXX.XXX dstport=80 dstintf="port1" dstintfrole="undefined" srccountry="Reserved" dstcountry="United States" sessionid=4222294 proto=6 action="close" policyid=1 policytype="policy" poluuid="f8bf71ea-18ad-51e7-3263-3e36007b6fd3" policyname="allow" service="HTTP" trandisp="snat" transip=10.XXX.XXX.184 transport=50968 appid=15893 app="HTTP.BROWSER" appcat="Web.Client" apprisk="medium" applist="TN-App" duration=30 sentbyte=356 rcvdbyte=5547 sentpkt=5 rcvdpkt=4 utmaction="block" countav=1 crscore=50 craction=2 ================================== Same logs for 6.4.3 pulling down an EICAR file via curl: Dec 22 13:38:07 10.XXX.XXX.98 date=2020-12-22 time=13:38:06 devname="FORTIGATE-6.4.3" devid="XXXXXXXXXXXXXXX" eventtime=1608673087572854902 tz="-0800" logid="0211008192" type="utm" subtype="virus" eventtype="infected" level="warning" vd="root" policyid=1 msg="File is infected." action="blocked" service="HTTP" sessionid=4954618 srcip=10.XXX.XXX.70 dstip=73.XXX.XXX.XXX srcport=47738 dstport=80 srcintf="port1" srcintfrole="undefined" dstintf="port1" dstintfrole="undefined" proto=6 direction="incoming" filename="eicar.txt" quarskip="Quarantine-disabled" virus="EICAR_TEST_FILE" dtype="Virus" ref="http://www.fortinet.com/ve?vn=EICAR_TEST_FILE" virusid=2172 url="http://XXX/eicar.txt" profile="TN-Virus" agent="curl/7.74.0" analyticscksum="131f95c51cc819465fa1797f6ccacf9d494aaaff46fa3eac73ae63ffbdfd8267" analyticssubmit="false" crscore=50 craction=2 crlevel="critical" Dec 22 13:38:41 10.XXX.XXX.98 date=2020-12-22 time=13:38:41 devname="FORTIGATE-6.4.3" devid="XXXXXXXXXXXXXXX" eventtime=1608673121980655620 tz="-0800" logid="0000000013" type="traffic" subtype="forward" level="notice" vd="root" srcip=10.XXX.XXX.70 srcport=47738 srcintf="port1" srcintfrole="undefined" dstip=73.XXX.XXX.XXX dstport=80 dstintf="port1" dstintfrole="undefined" srccountry="Reserved" dstcountry="United States" sessionid=4954618 proto=6 action="close" policyid=1 policytype="policy" poluuid="d007ffd4-6f31-51e8-00f8-20af0b5a45de" policyname="allow" service="HTTP" trandisp="snat" transip=10.XXX.XXX.98 transport=47738 appid=15893 app="HTTP.BROWSER" appcat="Web.Client" apprisk="medium" applist="TN-App" duration=34 sentbyte=488 rcvdbyte=64880 sentpkt=6 rcvdpkt=15 utmaction="block" countav=1 crscore=50 craction=2
Went for 6.4.4, logged into one of our SSL VPN portals via browser, /bin/log_sea starts to max out the CPU until it is killed.
The firmware lottery never ends.
Edit:
log_sea CPU usage ultimately goes down, after the SSL VPN portal has listed the recent user history.
Disabling web-mode for the SSL VPN portals works around the issue.
Edit 2:
TAC response: "As per my understanding you are facing an issue with Log-SEA CPU. Please be informed that this is caused by the log history in the webportal. So you can disable the history for all the portals. Please be informed that this is by design."
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 |
---|---|
1712 | |
1093 | |
752 | |
447 | |
231 |
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.