r/fortinet

Is anyone else having this issue or have had this issue in the past?

The firewall will show its memory at about 83 to 85% on the graph.

When this happens to it seems to kill routed network connectivity, I believe it's DNS that is handled by the Fortigate that is dying but I don't know that for sure.

I'm not the one troubleshooting it directly so I'm only getting some information. I do know this has happened before as well and simply restarting the active firewall allows the system to fall back to the secondary which doesn't have the issue for quite a while, but then it will come back.

Hi All,

We have updated our fortigate firewall 400E firmware from 7.4.9 to 7.4.12. After the upgrade our DHCP server is not releasing IPs on wifi vlan rest of the vlans are releasing ip. Does anybody face the issue,any solution?

Does anyone have issue using Fortiddns right now? An error shows up saying "Unable to check DDNS domain".

I can still ping the 2 domains that linked to my WAN1 and WAN2. I just can't modify it.

Internet access from internal is working fine.

FortiOS is 7.4.11.

https://preview.redd.it/7msm4avywe2h1.png?width=623&format=png&auto=webp&s=f2eb90295aa81e90096219dfce7986a9247878cf

https://preview.redd.it/26fd2ryowe2h1.jpg?width=767&format=pjpg&auto=webp&s=c0483deca94acfd58ea1a6944202a9abbc831ac7

Recently configured dialup IPsec /w IKEv2 and Azure SSO; Mode Config, IPs assigned from a specified range. Works great. No issues really.

DNS settings for the tunnel are configured for the internal DNS servers behind the VPN so clients can lookup specific resources. Split tunneling is enabled. Again. Test working!

Today I configured some new split-brain zones on our DNS servers to handle external access to an Internal/Exteral resource (PBX). To keep the tunnel traffic down, I setup a zone record to provide remote hosts (Hosts with IPs matching the IP Range in the VPN config) with the public IP of our PBX. That way when DNS lookups are done, the PBX's public IP is returned from the internal DNS server to those hosts. No need to use VOIP over the tunnel.

Firewall policy as its been working is VPNINTERFACE > LAN , VPN_Range > LAN_Range , (Services) > Allow

when connected, nslookup still resolves to the internal IP. The internal DNS server is not applying the dns policy to the VPN IP range and returning the public IP like it should.

So then I changed the firewall policy by turning off NAT.

Reconnected to VPN. nslookup resolves public IP of our PBX properly. now. DNS server receives DNS lookup from IP matching subnet in the DNS Zone policy and sends the proper response based on that policy. So my question:

TLDR; when NAT is enabled this policy, what is our DNS server thinking its getting its DNS requests from if its not getting them from the IP range in the policy?? Disabling NAT fixes the issue.

Currently running 7.4.11 on a range of 70G and 50G models.

Looking for any experiences with 7.4.12? And how they have gotten on.

Alternative is 7.6.6.

Hi everyone,

I recently upgraded two edge firewalls (200F) from FortiOS 7.2.12 to 7.4.12. The first firewall upgraded without any issues, but on the second one I ran into a strange LDAP authentication problem.

After the upgrade, LDAP users can no longer log in to the firewall GUI/CLI — it just returns “authentication failed.”

What’s confusing is:

-I can still log in locally with the admin account

-The LDAP configuration looks correct

-Connectivity seems fine

-“Test Authentication” succeeds successfully.

So everything appears normal, except the actual login using LDAP accounts.

Has anyone experienced something similar after upgrading to 7.4.12?

I already opened a ticket with Fortinet support and I’m waiting for their feedback, but I’d appreciate hearing if anyone here has seen this before or found a workaround.

Many thanks.

Hello,

I currently have two 90G in prod that works in an HA. My job as an intern is to change the current core (aruba) to two fortiswitch 648f that are connected in mclag. They will form the new core.

Currently, they are many vlans in the aruba. Do i have to reproduce them all in forticloud? Is there someone that have already migrated from aruba to fortinet that could give me some tips?

Thanks a lot

Imagine you have several SD-WAN peers and you use Central NAT to manage NAT based on your interfaces. You might have been very happy with FortiOS 7.2, 7.4 and the early ones in 7.6.

What if Fortinet decides that it's a good idea to drop the option to select individual interfaces in NAT and only allow your SD-WAN zone.

Great, isn't it?

But wait, what if you have to use specific "NO-NAT" rules like if there is a perimeter router with VPN on one leg?

... or one peer doing NAT/CG-NAT for you, the other doesn't?

... or if your SD-WAN interfaces do not have plenty free public IPv4 addresses? NAT Pool doesn't work.

Since individual interface selection has been removed, can't do either.

Support tells me that this is a "design decision" and I should contact my account manager for a new feature request.

What?

An essential feature has been removed and redesigned, the "design team" did not take into account some cases where the new design did not work anymore and then, to re-gain the same functionality as before, a NFR is required?

cmon...

Anyone else who misses the removed option?

The templates are referenced by the vlans, but the vlan's don't appear to have any way to be deleted.

mobileftg (core) $ conf switch-controller initial-config template

mobileftg (template) $ show
config switch-controller initial-config template
    edit "_default"
        set vlanid 1
    next
    edit "quarantine"
        set vlanid 4093
        set dhcp-server enable
    next
    edit "rspan"
        set vlanid 4092
        set dhcp-server enable
    next
    edit "voice"
        set vlanid 4091
    next
    edit "video"
        set vlanid 4090
    next
    edit "onboarding"
        set vlanid 4089
    next
    edit "nac_segment"
        set vlanid 4088
        set dhcp-server enable
    next
end

mobileftg (template) $ end

mobileftg (core) $ diag sys cmdb refcnt show switch-controller.initial-config.template.name "voice"
entry used by complex switch-controller.initial-config.vlans:voice (From VDOM: 'core')

mobileftg (core) $ conf switch-controller initial-config vlans

mobileftg (vlans) $ show f
config switch-controller initial-config vlans
    set default-vlan "_default"
    set quarantine "quarantine"
    set rspan "rspan"
    set voice "voice"
    set video "video"
    set nac "onboarding"
    set nac-segment "nac_segment"
end

mobileftg (vlans) $
set      Modify value.
unset    Set to default value.
get      Get dynamic and system information.
show     Show configuration.
abort    End and discard last config.
end      End and save last config.

mobileftg (vlans) $ end

mobileftg (core) $ get sys status
Version: FortiGate-60F v7.2.8,build1639,240313 (GA.M)

I've been tossing around the idea of doing a series of posts, maybe bi-weekly or monthly, highlighting a Fortinet product that isn't as well known... before I start putting in a bunch of work on this, is there an appetite for it? It would probably be pretty high level, but I run into situations all the time talking to customers about projects/concerns and mention a product in the FortiVerse they didn't know existed.

What say you Reddit Community?

Our company has received action required email from Fortinet global.

Serial Number	Current Firmware	Latest Firmware	Required Upgraded By
FG#############	7.4.11	7.4.12	May 15, 2026, PDT
FG#############	7.4.11	7.4.12	May 15, 2026, PDT

Notes said : Failure to upgrade within the 7-day window will result in restricted cloud connectivity and the suspension of log uploads for the affected devices.

Q. What if I don't want to update the firmware?
A: If not upgraded, access to the device from cloud and logging will be restricted. However, the device will continue to work standalone without cloud management. It is recommended to purchase FortiGate Cloud standard subscription to continue accessing and managing device from Cloud or if cloud management is no longer needed, deprovision the device.

Has anyone faced this kind of forced action requirement?
in this case we can't update our FortiGate for 2 weeks, but after 2 weeks we can update it by manually. So that after updating our FortiGate will it connect back to the cloud?

Having recently moved from Aruba (WiFi)/Sonicwall (firewall) to Fortinet, I felt totally underwhelmed about the reporting side of Fortinet, especially when it comes to WiFi troubleshooting. Compared to Aruba, simple tasks like checking the events generated by a WiFi client that was connected 12 hours ago feels so clunky, user-unfriendly and heavily log-focused.

After trialling FortiAIOps for a month (the trial was for 60 days, but the integration with the Fortigates broke midway), I thought that it was the closest thing I could get to a more interactive and dashboard-oriented way of display info and stats.

When the final quote came back though, I thought it was extortionate, also considering that I'm not using any of those 'AI' features and what I am using, should've been part of the core product anyway, not something we should be paying separately.

Am I missing something on what Fortigates can do, when it comes to WiFi troubleshooting, statistics and monitoring? Is there something else out there that can do what I want to do, without having to pay the equivalent of a small flat?

Basics of the situation. Deployed 3 gates at a customer site. One being the main for ipsec client termination. Deployed to 120 desktops. Ems cloud. Not thinking I just made the deployment and pushed with intune days before. Long story short. Ems does not work with the version I deployed. So now need to walk back installs on 120 workstations. Had to powershell a rip out followed by a replace of the client (7.4.3.1709) otherwise it's. Hit nightmare. Anyone else?

I'm thinking of upgrading my home firewall from the 120G to the 200G for the additional 10 GbE ports as I have 10 Gbps Internet and also want stateful LAN filtering.

The 120G is noise rated at 49 dBa and is quiet enough for a closet. The average power is rated at 38 W, which I measured to be 15 W / 28 VA (power factor of 0.56) when idle.

The 200G is noise rated at 48 dBa (1 dBa lower than the 120G) but posts about the older 200F say it's loud. I'm skeptical about the low noise rating given the average power is rated at 145 W and it has a separate X86 CPU instead of an ARM SoC.

Does anyone have experience with the 200G noise level end idle power?

I am trying to run and download a report that I already created via API

I am trying to figure out what put in the aparams

I have:

apiver: 3

"url": "/report/adom/root/reports"

data: {"report": MY_REPORT","schedule":"now"}

Everything runs but I am not getting any output, am I putting in the right data?

I also have no access to fndn and I am waiting to hear back from my rep on this.

Hi all,

We are seeing a strange issue with our FortiAnalyzer after upgrading from 7.4.9 to 7.4.11.

FortiAnalyzer:

Platform Type: FAZVM64
Firmware Version: v7.4.11 build2804 (Mature)

We have multiple FortiGates streaming logs to this FortiAnalyzer. We also use ADOMs for segmentation. Most of the FortiGates are also running 7.4.11.

In general, the logs are still arriving on the FortiAnalyzer and we can view/search them normally there. However, on some FortiGates it is no longer possible to view the logs directly in the FortiGate GUI.

As a workaround, changing the forward-log setting to memory allows the logs to be viewed locally again.

What we noticed so far:

• The issue seems to affect only FortiGates using VDOMs
• From our spot checks, all VDOMs on the affected firewalls seem to be impacted
• The FortiGates are still sending logs correctly to the FortiAnalyzer
• In Security Fabric / Fabric Connect, the FortiAnalyzer also appears to be connected and embedded correctly
• A sql rebuild-db on the FortiAnalyzer did not improve the situation
• I did not find anything obvious in the 7.4.11 release notes related to VDOM log viewing or FortiAnalyzer log integration

It is not urgent for us, since the logs are still available on the FortiAnalyzer, but I wanted to ask here before opening a TAC case:

Has anyone else seen this behaviour after upgrading to FAZ/FortiGate 7.4.11, especially in environments with VDOMs and ADOMs? Or has anyone experienced something similar with other 7.4.x releases?

Anyone else having this issue? It appears to only happen when we are upgrading from 7.4.5 or 7.4.6 via EMS to 7.4.7.

We are cloud hosted on EMS and push the update from there. During install, Bitdefender crashes, states there's an error that requires a reboot and protection is compromised. So far as I can tell the upgrade for Forticlient goes smoothly with no issue and hasn't required a reboot.

in the Bitdefender console, it states "Anti-Tampering has detected an unauthorized attempt to disable or remove the security agent’s callbacks. The product‘s integrity has been compromised." And cites an error with a file bddci4. I've attempted to add an exclusion, but that seems not to be working.

I've tried to raise a ticket with Bitdefender, but it's been two weeks, they aren't reading anything I write to them, and are still just asking for more and more logs. I'm getting to the point where I'm ready to just disable anti-tampering callback evasion, throw Bitdefender in the trash and find a new security vendor.

Hello, as SSL-VPN is removed from 7.6.3 and above and currently we still on 7.4.11 im working on getting the IPSEC VPN Client connection set up before migrating to 7.6.x.
We have lot of site-site IPSEC tunnels setup, and I need to keep these running with out any changes.
Also I need to switch the IPsec port from UDP 500/4500 to TCP (9443 for example) as we have some remote users which their ISP block IPsec ports.

Does changing the IPsec port now will break all the current running IPsec ? Or I can change only the port for this specific remote dial up VPN

Appreciate your help on best option for this migration

Dear all

I manage a lot of seperate Fortigate firewalls (40F, 60F and 80F), all with the latest version of 7.2. installed. These firewalls are at seperate customers, all with their own standalone configuration.

Since this Saturday I got message from my monitoring tool that the CPU is maxed out on pretty much all of them. I can log in via SSH and was able to verify that it's httpsd that causes the spike. Restarting the service didn't help - it spawns a lot of child processes.

I can - for the life of me - not figure out why that is and why it started on Saturday. HTTPS access is prohibited on WAN interface, they are however reachable via SSL VPN on the WAN port - I am yet to migrate to ZTNA.

Do we know of a federated attack starting this weekend?

Looking forward to your help.

EDIT: I need to correct myself: It only happened to the customers where I never disabled HTTPS access on the WAN interface. Log showed 100s of login attempts - no wonder httpsd broke.

I was able to login via SSH and disable HTTPS access, then kill all httpsd services. Problem solved.

config system interface
edit wan1
unset allowaccess
end
fnsysctl killall httpsd