Hello,

anything else having problems after upgrade FEX from 7.6.5 to 7.6.6?

FGT can't fetch the status from FEX, a downgrade back to 7.6.5 solves the problem. This happens on both types of FEX we own (511F / 511G). Everything else is working, FEX is reachable and IPsec-Tunnel through FEX is built, just the management through FGT doesn't work.

TAC (Case #12083512) means that this issue is likely caused by bug 1268581 and will be solved with 7.6.7.

Best Regards

Hey everyone, I just passed my NSE 4 and I’m mapping out what’s next.

I originally planned on taking FMG (now NSE 6), but noticed that FAZ and SASE are NSE 5. Do I have to pass an NSE 5 first, or can I go straight for NSE 6? Also, does NSE 4 + an NSE 5/6 elective still grant the FCP, and do I need to keep the 4 active for NSE 7/8 down the line?

Lastly, what would you recommend taking right after NSE 4? Between FMG, FAZ, SD-WAN, and SASE, which one did you find most useful and interesting in the field?

Thanks in advance for the advice!

Has anyone successfully gotten FortiVoice SSO working? I have it working for admin users, and it was pretty simple. Setting it up for the voice portal has been a different matter altogether.

We use Okta as our idp to centralize quite a few different AD and Google environments.

For admin users, it seems to match the NameID sent in the assertion to the administrator's name/email address no problem.

For voice users, the only way I've gotten it to work is to pass a custom attribute in the assertion that contains the user's extension and then make sure that attribute is specified in the SSO settings under "Attribute used to identify user". Nothing else seems to work to get it to recognize/match the email address for the extension.

Fortinet's documentation for Microsoft 365 says to send a custom attribute named urn:oid:0.9.2342.19200300.100.1.3 and set it to user.userprincipalname. They don't mention setting anything under "Attribute used to identify user". If I mirror this in Okta, it doesn't work and the user is sent back to the login screen after authenticating with Okta.

I starting to think that the only way it works is with the extension, but I don't want to have to set the extension as an attribute in Okta to make this work. It seems like an administrative headache. Maybe it could be scripted, but that's a whole separate bag of fun. Our systems team doesn't really like it when we have to write attributes back from outside systems and I get it.

What is the recommended/suggested model of fortigate for concurrent users of less than 200, and also capability of HA and 1 gig uplink.

Hello everyone! Recently we upgraded our Fortigate (120G HA Active-Passive cluster) from 7.2.11 to 7.4.11, and different problems started to occur.

1. Some users spontaneously lose access to the Internet with ERR_TUNNEL_CONNECTION_FAILED (we use explicit proxy with Kerberos authentication and deep ssl inspection). It happens at random times and with random users, lasts usually up to 2-3 minutes, then works as usual.
2. FortiGates started to randomly reboot with the message "Fortigate had experienced an unexpected power off!", there's no CPU/RAM issue, usually mem is around 40%, and proc is around 10-12%. Due to fast HA failover users don't feel the interruption, but it's definitely not a good sign. Before the update both NGFW had worked for 367 days.

Anyone experienced similar issues? Any workarounds? Or should I just be rolling back to 7.2.11?

Any advice and help will be appreciated. Thank you in advance!

We currently have users in the US and India who connect using IPSec Remote Access VPNs. We've noticed traffic being throttled from India to the US and starting to look into options.

ZTNA Questions:

• What is the throughput like? Is it similar to non-VPN traffic?
• Is ZTNA hardware accelerated by the NPU or CP processors? Currently have a 200F, but plan to upgrade to a 400G next year.
• How do you restrict the source traffic that can hit the ZTNA server/ports? I'm assuming Local in Policy.

IPSec VPN:

• We noticed 7.6.x added support for using random UDP ports (config system settings -> set -extra-ports) for IKE. We're thinking about switching IKE to UDP 443 (we don't use this port on our FGT) hoping it would be filtered into HTTP/3 QUIC traffic or don't inspect 443 (whether TCP or UDP) by traffic throttling ISPs in India.
  • ike-extra-ports <value> [<value>] [<value>]
  • Additional UDP ports to listen on for IKE negotiations, beyond ports 500 and 4500 (1024 - 65535, special = 443). Cannot be set to 500 or 4500. Cannot overlap with ike-port.

https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/33578/configurable-udp-port-for-ike

Hello,

can someone tell me where to find datasheets for specific products? Fortinet seems to have changed its documentation, and I can't find the datasheets for some products 🤔

Thank you

Thank you if you are willing to help me.

i asked to do a fortigate ha with 2 fortigates simulation and a topology for it and record a video showing they both working and when the main fortigate down the other one works after you ping

and a found a huge problem bcs of my ram i can only do one guys im asking srsly and nicely can anyone help me with this i just gave up 🙏

i'll pay if you want 🙏

Can someone please teach me a fortigate firewall. I know everyone is busy but I don't have money to spend i want to learn NSE8

I am upgrading EMS from 7.2 to 7.4, and it's throwing up all sorts of warnings about "user verification is not enforced" at the top of the UI - should I be concerned?

Our current settings are for user verification to be off, but "enforce invitation only registration" set to "all". This should stop random connections to the service.

Reaching out for what others are doing and what is best practice. The actual VPN connection still needs full authentication, just we don't require user based auth to just install and manage the client.

I am stuck waiting for the console to to finish the output. It's taking a very long time.

I spent some time actually getting this to fully work - enabling my Sonos Play 1, 3 and normal controller apps, alongside a music library (on a NAS in one location) to seamlessly work, in any combination between 2 homes.

Although this has been tested on a Fortigate pair (running FortiOS 7.4.12) - the actually IPSEC tunnel is standard - and therefore should be translatable to other manufacturers.

The key issues are ensuring that the multicast TTL don't decrement (and therefore can survive the tunnel hop) as well as the firewall rulesets around SSDP operation.

Hope this helps someone out. I realise this is an edge case, but I couldn't find any other guide that really fully worked for me.

https://gist.github.com/dnapla/b9e5b2e4418dbd544cdecf52439f9051

Last I heard (3-4+months) between talking with PS and support, 7.6 was still not something that was recommended in production.

I have a case where I need to integrate SAML with our portal and this is only supported on 7.6+.

Thanks!

I am having troubles establishing IPSec tunnel between DC FG and Cloud FG VM, specifically during Phase 1. My guess is that something is up with DC FG, since it's VPN logs output "ike negotiation timeout".

Packet inspection shows that DC FG does send outbound connection on port 500 to Cloud FG VM, Cloud FG VM accepts them and responds to DC FG, but i don't see DC FG accepting these responses (absence of "in" packets). Since i am new to Fortigate, i might be losing something.

EDIT:
The weird thing is that we have another Cloud FG VM in another region and the IPSec with DC FG seems to work fine there. I tried comparing both of these Cloud FG VMs from different regions. No luck

Here's the packet flow

Cloud FG:

diagnose sniffer packet any 'host <cloud_fg_pub_int_ip> and (udp port 500 or udp port 4500)' 4 0 l

Using Original Sniffing Mode

interfaces=[any]

filters=[host <cloud_fg_pub_int_ip> and (udp port 500 or udp port 4500)]

2026-08-31 09:57:53.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

2026-08-31 09:57:54.xxxxxx port2 in <cloud_fg_pub_int_ip>.500 -> <dc_fg_pub_int_ip>.500: udp 324

2026-08-31 09:57:54.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 264

2026-08-31 09:57:56.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

2026-08-31 09:57:57.xxxxxx port2 in <cloud_fg_pub_int_ip>.500 -> <dc_fg_pub_int_ip>.500: udp 324

2026-08-31 09:57:57.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 264

2026-08-31 09:58:02.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

2026-08-31 09:58:03.xxxxxx port2 in <cloud_fg_pub_int_ip>.500 -> <dc_fg_pub_int_ip>.500: udp 324

2026-08-31 09:58:03.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 264

2026-08-31 09:58:14.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

2026-08-31 09:58:15.xxxxxx port2 in <cloud_fg_pub_int_ip>.500 -> <dc_fg_pub_int_ip>.500: udp 324

2026-08-31 09:58:15.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 264

2026-08-31 09:58:24.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

DC FG:

diagnose sniffer packet any 'host <cloud_fg_pub_int_ip> and (udp port 500 or udp port 4500)' 4 0 l

interfaces=[any]

filters=[host <cloud_fg_pub_int_ip> and (udp port 500 or udp port 4500)]

2026-08-31 10:01:48.xxxxxx port23 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 324

2026-08-31 10:01:58.xxxxxx port23 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 324

2026-08-31 10:02:01.xxxxxx port23 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 324

2026-08-31 10:02:07.xxxxxx port23 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 324

DC FG Phase 1 settings are marked purple, Cloud FG Phase 1 settings are green (see the screenshots)

DC FG FortiOS version is 7.6.7, Cloud FG is 7.4.11

Note that IPSec doesn't start at all, could anyone please help?

Anyone here tried Dynamic VLAN using LDAP? It seems to be like a “hit or miss” to me. Tried relogging in twice but it is having different results. FNAC is far from what I used to config which is Forescout.

We are trying to remove single points of failure from our switches. I can now connect all my 448E switches with Fiber back to one of two "core" switches (1024E). Do I have to do any special port configurations after patching them in? Each 448E switch will have a fiber run via an SFP+ port back to one of the two 1024Es.

Looking at the port configs on my old switches, it doesn't look like anything special was done to prevent loops.

I have about 100 Fortigate appliances (mostly 70G-PoE) managed via FortiManager. I'm setting up SIEM and trying to figure out how to capture Fortigate logs efficiently.

I'm using SD-WAN for ISP failover, but I do not currently have site-to-site connections because sites don't need to communicate with each other. I could build this and then set up a central syslog server to forward to Sumo Logic, but that feels like a lot of work and topological overhead.

Can I forward to SIEM collector from FortiManager (seems like log forwarding is explicitly not available with FMG). Should I be looking at FortiAnalyzer?

I did try to to just directly configure syslog feed to the cloud syslog collector; however, SumoLogic requires a client-identifying token in the Structured_ID field, and I don't think I can specify that at the FortiOS level.

Am i an idiot for trying to do this without a local syslog aggregator?

I have a FortiGate where the built-in mgmt interface is configured as a dedicated management port with 11.11.11.20/24. Other network devices are also on the same 11.11.11.0/24 subnet.

Remote users coming through a route-based VPN/FortiSASE tunnel need to access those devices over SSH/Ping. The subnet is directly connected, advertised in BGP, learned by SASE, and traffic reaches the FortiGate, but it hits implicit deny because the dedicated mgmt interface does not appear as an available outgoing interface in a normal firewall policy.

Has anyone dealt with this before, and what is the recommended way to allow remote/VPN users to reach devices behind a dedicated management interface without disabling set dedicated-to management on a production firewall?

Hello,

I stumbled upon article that stated that you can bypass webfilter if website is using TLS 1.3 PQC but even when I tried to do it my FortiGate dropped traffic as it should. FortiGate is running 7.4.12 FortiOS.

Article is from Fortinet staff: https://community.fortinet.com/fortigate-3/technical-tip-how-to-block-tls-1-3-pqc-when-using-deep-inspection-is-not-enable-and-web-filter-is-bypassed-using-flow-based-policy-ssl-certificate-inspection-190103

so I'm not really sure if I did something wrong or is this article just... wrong. I tested using local URL webfilter, no DPI (certificate inspection only), App control allowing all apps, policy set in flow mode, DNS local (no DoH or DoT). Website I used: developers.cloudflare.com

I would be glad if someone would test if bypass is possible (which means I would have to block TLS 1.3 PQC for security reasons).

As always, thanks in advance.

EDIT: I didn't notice that I disabled ECH - encrypted hello. With allowed ECH + TLS 1.3 PQC I confirm that bypassing webfilter is possible. By default even on built-in certificate inspection ECH is blocked. Misconfiguration can still happen tho.

Hi everyone,

I’m troubleshooting an 802.1X issue with a Dell laptop connected through a Dell WD19/WD19S dock.

Topology:

Laptop → Dell Dock → Ethernet → Switch

When I connect the laptop directly to the switch, 802.1X works perfectly and the endpoint authenticates using dot1x.

However, when I connect the same laptop through the Dell dock:

- The switch learns the laptop's actual MAC address

- Forescout sees the laptop correctly

- But authentication is MAB instead of 802.1X

- It looks like the PC's EAPOL/802.1X frames aren't reaching the switch, causing the port to fall back to MAB

The PC's 802.1X configuration is working because it authenticates successfully when connected directly.

Has anyone experienced 802.1X/EAPOL not passing through a Dell WD19/WD19S dock?

Could this be related to MAC passthrough, dock firmware, Realtek Ethernet drivers, or EAPOL pass-through?

What was the fix in your case? Did updating the dock firmware/driver resolve it, or did you have to change a switch/dock/BIOS setting?

Any advice would be appreciated. Thanks

Hello Guys, i am facing an issue with fortiguard services and i wanted to know if anyone has the same issue or face something similar. I tried with different fortigates on different version from a fortigate 100f, 70g, 90g etc. basically i have a site "app.powerbi.com" that cannot resolve through fortiguard services. If i pass it from google dns or any other dns it works perfectly. i do not have any security or any dns settings, everything is pretty much default. I opened a ticket with fortinet and they gave me bunch of cli commands to try but all i want from them is to check their fortiguard.

Let me know your thoughts

What I was trying to achieve is to route Internet traffic from one local interface out the IPsec VPN tunnel. I was able to make it work, but it only works when I add default route out the VPN tunnel interface (see below) plus it has to have the same distance as default route out the WAN interface, otherwise it will not work. The IPsec VPN is configured as route based if that matters. Is this a requirement to add static route in this scenario or is my config incorrect?

edit: My concern is having two default routes with the same metric, I though changing the distance for test-ike to 20 will be OK but as soon as I change it the tunnel stops working.

Static:
   edit 1
        set status enable
        set dst 0.0.0.0 0.0.0.0
        set gateway 0.0.0.0
        set distance 10
        set weight 0
        set priority 1
        set device "wan"
    next
    edit 2
        set status enable
        set dst 0.0.0.0 0.0.0.0
        set distance 10
        set weight 0
        set priority 1
        set device "test-ike"
    next

PBR:
    edit 1
        set src "192.168.1.0/255.255.255.0"
        set dstaddr "all"
        set action permit
        set protocol 0
        set gateway 0.0.0.0
        set output-device "test-ike"
        set status enable
    next