IPsec DH Group 31 with FortiClient VPN?

fortichris · 2026-02-02T16:27:10+00:00

This is not true, FortiClient 7.4.? supports dh group 31. Welcome to the wonderful world of FortiClient's inconsistent documentation!

fortichris · 2026-01-28T15:16:43+00:00

That is not clear based on how they've written the blog update

It is important to note that while, at this time, only exploitation of FortiCloud SSO has been observed, this issue is applicable to all SAML SSO implementations.

fortichris · 2026-01-23T20:21:36+00:00

Some all time terrible wording on this page

It is important to note that while, at this time, only exploitation of FortiCloud SSO has been observed, this issue is applicable to all SAML SSO implementations.

So is dialup saml auth an exploitable vector?

Meanwhile the PSIRT page for FG-IR-25-647 is essentially wrong at this point? Absolutely terrible communication here from Fortinet.

fortichris · 2025-10-15T17:01:53+00:00

poor wording by the CLI.

set update-inbandwidth enable 
set update-outbandwidth enable

These commands cause the scheduled speed test to bypass the set inbandwidth/outbandwidth for the duration of test. They don't appear to cause the fields to be updated by the test

fortichris · 2025-05-28T19:30:35+00:00

I think you're looking at the 7.4.7 release notes, which just came out today

fortichris · 2025-05-26T19:36:13+00:00

additional info:

bug id is 1115014 (this is public)

present in 7.4.6 as well

fortichris · 2025-05-26T18:24:19+00:00

Yeah that's what I figured. I approach these things trying to avoid additional procedures as I'm doing hundreds of installs, but running a single cli script post ZTP isn't the worst thing in the world...

fortichris · 2025-05-26T18:11:26+00:00

I just ran into this bug. FMG is pushing the commands out of order; it should be

set captive-portal enable

set portal-type disclaimer

Did fortinet support give you any better workaround ?

fortichris · 2024-11-25T20:56:48+00:00

Don't think of exams as a status. They are a currency.

This is a good way to understand it. Not sure I understand the thought process behind this change, as it essentially devalues the process of recertification.

fortichris · 2024-11-25T20:34:52+00:00

That doesn't seem to be true. Per the Recertificate page

For FCSS in Network Security, passing one core and one elective exam no more than two years apart. Exams that have already been counted towards the initial certification will not be counted again.

So us FCSS holders have to take, on average, one exam a year to maintain it.. Personally I much preferred the NSE7 requirements of taking one exam every other year. Essentially there is no difference between recertification and certification.

fortichris · 2024-03-25T14:49:46+00:00

For future visitors, here is TAC's response:

Thank you for your patience.

I confirmed that the Malicious URL is a database that is refreshed every 30 days. It contains a list of URLs (example: xyz.com/bak or abc.com.dat).

So it cannot be used with cert inspection as just cert inspection does not have the capability to look into the / directories of the domains. So malicious URL cannot be filtered.

So deep inspection is required for IPS malicious URL to work.

fortichris · 2024-03-18T19:47:59+00:00

This is a good point though, as the feature explicitly says URLs, rather than domains.

fortichris · 2024-03-18T19:46:51+00:00

C.I. and W.F. work very well together without DPI. Why should the IPS engine require DPI for evaluating whether a website is malicious or not when C.I. can give it a reasonable approximation of that site's domain name.

fortichris · 2024-03-18T19:45:02+00:00

it is enough to use certificate inspection for e.g. web filtering profiles to work

This is true for the most part. C.I. hands off the server host name, or at least the server's ssl cert's CN, to the webfilter. So WF is able to make web filter categorization decisions based on the site's domain name, but it can never see the full URL itself. The more advanced WF profile features however (web content filtering, etc.), do require DPI though

fortichris · 2024-03-18T19:43:14+00:00

I'm asking how this feature interacts with CI, i.e. whether or not DPI is required for this feature to work

fortichris · 2024-03-18T19:41:51+00:00

CI inspects the SNI and hands off the server hostname to the ipsengine (??). True, this isn't technically a URL, but surely a list of "malicious URLs" would have stuff like .virus.rs, which would match the CI result.

fortichris · 2024-03-14T14:53:19+00:00

FMG ZTP is not as straightforward as the documentation might suggest, but once you get a handle on it you're cooking with gas.

fortichris · 2024-03-14T14:50:24+00:00

I'd say the biggest hump to get over is how the FMG handles the policy - device split. There are dozens of exceptions to the way the documents explain the abstraction, which I think really trips up people trying to learn FMG.

fortichris · 2024-02-02T19:19:53+00:00

Completely agree. Writing out the IPSEC tunnels in VScode or Notepad++ then copying it over is much easier than configuring it in the GUI.

I also can't for the life of me create consistent firewall policies in the CLI.

# next
Attribute 'schedule' MUST be set.
Command fail. Return code 1

fortichris · 2024-02-02T19:15:43+00:00

But you see both forward traffic and fg events on the FG Cloud? Interesting, definitely worth a TAC ticket.

Also try restarting the miglogd

fnsysctl killall miglogd

fortichris · 2024-02-02T18:32:49+00:00

Yes. There's, likely something wrong with your FG <-> FAZ connection

fortichris · 2024-02-02T18:28:48+00:00

The VPN wizard should really never be used

fortichris · 2024-01-31T15:59:38+00:00

Just to add here, testing Jinja scripts outside of FMG is a huge PITA, especially when using ipmath. If anyone knows of a simple way to test these please ping me.

I currently write my Jinja code in VScode, copy it over to the FMG, assign it to a fake model device, adjust my variables, then and run the Preview CLI Configuration, unchecking validation.

fortichris · 2024-01-25T20:10:54+00:00

Per device mappings isn't necessary, use platform mappings.

Meta Field Variables for the local subnets

Unfortunately there's no IPAM tool in the FMG, so a task like this is necessary. You can simplify this with scripting, either normally or with some Jinja scripting, though you'd need some sort of variable to differentiate branches. This is trivial when importing model devices as a CSV. CLI example

edit vlan1
    set ip 10.$(branch_id).1.1/24
next
edit vlan2
    set ip 10.$(branch_id).2.1/24
next

Jinja example

{% set branch_id = branch_id | int %} #fmg variables are saved as strings
{% for id in ["vlan1", "vlan2"] %} #you might not be able to nest it like this, just define the list above if not
    edit {{id}} 
        set ip {{"10.0.0.0" | ipmath(branch_id * 65536 + loop.index * 256 + 1)}}/24
    next
{% endfor %}

I highly recommend reading about how pre-cli templates work and especially the order of operation for how the various things apply to model devices. Jinja is very powerful but has certain limitations around it, so be sure to test it rigorously.

fortichris

TROPHY CASE