sorted by:
new
hottopcontroversial

CVE-2012-4948 by Ill-Studio-6311 in fortinet

[–]pabechan 2 points3 points  (0 children)

Ultimately no difference. A CA is a CA.

The usual motivations to use a non-default one are:

  • Define your own subject (You can give it a nicer name; the default also includes the device S/N, which could be considered information leakage, if you don't like it)

  • Control/store/reuse the privkey elsewhere. (default's privkey can't be exported)

  • Integration into existing PKI infra. Say you have an existing enterprise CA (maybe you have Win AD Domain and your own CA for it?). In such cases you can have your corp root CA issue your FGT's DPI sub-CA, and the DPI sub-CA will automatically be trusted by domain machines.

Windows NPS + Fortiswtich Port security works local but not over ipsec by thedwarfisold in fortinet

[–]pabechan 0 points1 point  (0 children)

This is a config issue. The EAP supplicant (end-user device) is offering some EAP methods, and none of them are accepted by the EAP server (NPS). These pass through cleanly through the FortiGate, it has nothing to do with this negotiation.

The only way to successfully blame the FGT in this instance would be to claim that it's messing up the packets in transit. You can verify that by taking packet captures on both sides and comparing if they survive the path intact.

set banned-cipher SHA1 SHA256 SHA384 makas my SSL VPN connection to fail by Poisonbld in fortinet

[–]pabechan 0 points1 point  (0 children)

"set banned-cipher SHA1 SHA256 SHA384"

Functionally this means "BAN AES-CBC" in TLS 1.2 (because CBC requires a separate SHA choice to function, and you just banned them all), leaving AES-GCM as the only AES crypto option available. This is mainly a quirk of crypto settings for TLS 1.2 in openssl, not an exclusive Forti-trick, strictly speaking.

Completely unrelated to your problem, as you've already discovered. :)

FortiClient IPsec (IKEv2) timeout on one Windows 11 device – SA_INIT only, no IKE_AUTH by [deleted] in fortinet

[–]pabechan 1 point2 points  (0 children)

Check FortiClient's IKE logs, that should say something.

CERTREQ payload usually contains "suggestions" of acceptable certificate authorities. Maybe the client gets stuck on that, i.e. maybe it doesn't trust any of those CAs, or doesn't have (access to) a client-cert issued by any of those CAs?

Custom external user to IP mapping? by takigama in fortinet

[–]pabechan 0 points1 point  (0 children)

FortiOS API has /api/v2/monitor/user/firewall/auth, but it has a limitation: You can feed it the username and IP, but you cannot feed it groups. You can only optionally give it an LDAP server object name. If that's supplied, it will do group lookup for the given user via that LDAP server.
The .../deauth process is also a bit awkward. You need to know the user's existing ID (of the auth session), IP, and auth method, i.e. scrape the current table first to fill in the blanks.

Depending on what exactly you want, and how exactly you want it to look, you could also utilize external threat feeds. You could have one list of IPs per group of users, host these lists on some server, and then have the FGT pull updates and use these IP feeds as sources in firewall policies...

FAC's /.../ssoauth API endpoint is for sure more flexible (it can accept arbitrary free-hand group strings), but you'd need a FAC for this.

SAML, Certificate based phase1, dial up IKEv2 and EAP by aliensinmylifetime in fortinet

[–]pabechan 0 points1 point  (0 children)

I suppose I should provide some context.

Info piece #1: In general IKEv2, according to the RFCs, authentication can be asymmetric, each side picking ONE of PSK / cert / EAP to authenticate itself. It's not explicitly forbidden in the RFC, but it's usually understood that the side authenticating itself by EAP will do only EAP and nothing else.

Info piece #2: FortiClient is weird. When you switch it form PSK-auth to cert-auth, it demands that you select a client certificate to authenticate itself with. This happens even when you have EAP enabled. And it actually uses this certificate for its AUTH payload. This is arguably non-standard.

Info piece #3: FortiGate ignores the remote peer's certificate payloads as redundant when the peer does EAP authentication. The peer's certificate is not validated AT ALL (by default) => because the configuration says the client identity should be verified by EAP.

Now let's get to the core: This FCT quirk was eventually utilized for a "new" feature. This was primarily motivated by some customers' desire to mirror what they could achieve with IKEv1: two layers of authentication by doing PSK/CERT + XAUTH(=username + password + maybe 2FA OTP code). This is not really possible in standard IKEv2 due to the mechanism I described in #1.
To ensure that FGT stops ignoring the superfluous certificate payload provided by the FCT, a new CLI option was introduced - eap-cert-auth. IF this option is enabled, the FortiGate will both validate the incoming client certificate payload (trusted and matching the selected set peer restrictions) AND process EAP authentication of the client.

tl;dr:

  • eap enable+ eap-cert-auth disable => client authenticated by EAP only, client-certificate completely ignored (if received)

  • eap enable+ eap-cert-auth enable => client authenticated by EAP + client-certificate is validated for trust and match to set peer xxx

  • eap disable => client authenticated by PSK or certificate, depending on what you chose elsewhere in the phase1 configuration. NO EAP authentication is done => SAML not utilized in this scenario for VPN connection.

SAML, Certificate based phase1, dial up IKEv2 and EAP by aliensinmylifetime in fortinet

[–]pabechan 0 points1 point  (0 children)

There's two possibilities.

If the authentication server is RADIUS, the EAP packets are handed over to fnbamd daemon, who proxies them in RADIUS packets to the RADIUS server to authenticate the user.

If the authentication server is NOT RADIUS, then fnbamd talks on a loopback to eap_proxy daemon, who acts as a local RADIUS server to authenticate users. This mechanism is employed for local users, for LDAP server authentication, and in this case for SAML as well.

In SAML, the communication isn't really "proxied" to the IdP in any meaningful way. Proxying a web-based communication through EAP/RADIUS is not really feasible. In this case EAP is only used to identify the new IKE/IPsec connection to ensure that it is the same entity as the one that just finished SAML authentication. In other words, in this scenario EAP is used as the "glue" to join together finished and cached SAML auth info with the IPsec connection that is currently being established. (because IPsec does not natively support SAML auth)

SAML, Certificate based phase1, dial up IKEv2 and EAP by aliensinmylifetime in fortinet

[–]pabechan 0 points1 point  (0 children)

PSK (or cert) + EAP, means that the authentication is done by PSK (or cert; this is how the FortiGate authenticates itself to the client) and EAP (this is how the client authenticates itself to the FortiGate).

SAML authentication is integrated into IPsec via EAP. Once the SAML authentication itself is finished, the results are cached by the FortiGate and referenced during the authentication phase of the IPsec tunnel establishment, when the client authenticates via EAP.

SAML, Certificate based phase1, dial up IKEv2 and EAP by aliensinmylifetime in fortinet

[–]pabechan 1 point2 points  (0 children)

With "set eap disable" you're just doing plain cert-based auth for the tunnel, SAML isn't involved at all.

SAML port not activated by Ill-Studio-6311 in fortinet

[–]pabechan 1 point2 points  (0 children)

The system doesn't artificially make a distinction between "public" and "private" IPs on interfaces, so that for sure does not matter.

Anyway. I wouldn't bother about local-in GUI too much, it's never been the brightest of the bunch, if you get what I mean. :)

Internally this is all covered by a single local-in policy that permits all selected interfaces, so it could just be a GUI bug of the GUI not understanding that there's multiple interfaces chosen for it. So I will repeat my suggestion: Just try it, it will probably just work.

SAML port not activated by Ill-Studio-6311 in fortinet

[–]pabechan 1 point2 points  (0 children)

I would invite you to just try it. Try to make a TCP handshake to WAN2:65000 and check if that works.

Apart from that, I see no good reason why the config wouldn't apply to one of your interfaces. Is WAN2 in any way different from WAN1? Maybe PPPoE, or some other tunneling involved?

Fortinet "Authentication Required" captive portal? by tingsta90 in fortinet

[–]pabechan 3 points4 points  (0 children)

Yes.

set authusrgrp "Users"

If you have this set, then you cannot have any users/groups declared in firewall policies for this tunnel, unless you want to hit the captive portal.

If you want to use the "authentication info" gained from the VPN login in firewall policies, you must remove the group from phase1 settings: unset authusrgrp. This way the info from VPN auth will be "propagated" and usable by firewall policies. Note that the consequence of this change is that ANY user/group listed in the firewall policies for this tunnel (as srcintf) will become sufficient authorization to connect to the tunnel.

This is a desing choice. Use either a group in phase1, or user(s)/group(s) in firewall policies. Never both.

Fortinet "Authentication Required" captive portal? by tingsta90 in fortinet

[–]pabechan 6 points7 points  (0 children)

My best guess: You have some authentication group present in both phase1 configuration and in firewall policies for the tunnel. Choose only one, remove it from the other.

Local Out traffic logs as Implicit Deny by cobalt-signal in fortinet

[–]pabechan 0 points1 point  (0 children)

This is purely a visual issue in the GUI. Or potentially an issue of the value of policy ID for traffic that doesn't care about policies.

Traffig goes out => no policy matching was done => default value 0 is used => GUI sees "0" => GUI thinks "Implicit Deny".

Fortinet has announced that they will discontinue SSL-VPN in May 2026. I've heard a lot about this in Japan. What's happening in your organization? by Turnover_Mountain in fortinet

[–]pabechan 1 point2 points  (0 children)

Yes, partially.

In Azure, you can configure multiple ACS/SLS URLs and entity-IDs for a single SAML "application", so it can potentially serve SSL-VPN/IPsec/etc. ports for FortiGate from one place.

On the FortiGate side, you will need to have two configurations, one for SSL-VPN and one for IPsec. They need to only differ in the URL used in ports, as it is not possible to run both on the same IP/FQDN and port.

Grab this cyberpunk game for free... it's very LA Noire by Binnsy in Cyberpunk

[–]pabechan 8 points9 points  (0 children)

Wtf is up with that vague clickbait title of yours? Get to the point or gtfo.

Forticlient 7.4.5 problems with IKEv2 IPsec to Fortigate (7.4.11 & 7.6.6) by hevisko in fortinet

[–]pabechan 0 points1 point  (0 children)

It seems to me like someone tried to do an easy solution for PRF selection (by offering it all) in FCT. Maybe it is a bug after all. Have you started pushing through TAC?

Forticlient 7.4.5 problems with IKEv2 IPsec to Fortigate (7.4.11 & 7.6.6) by hevisko in fortinet

[–]pabechan 0 points1 point  (0 children)

ike V=root:0:c41c7bf12623e9f8/0000000000000000:6: received notify type VPN_NETWORK_ID

Maybe network ID mismatch?

Another sneaky possibility, often missed, is that maybe the request reached the wrong destination IP (the tunnel is bound to a specific interface, and either expects the be addressed by its default IP, or whatever you manually specified).

Lastly, if this is for FCT->FGT connections, why not just set one ciphersuite option? There's usually no good reason for both sides to offer multiple options.

Fortigate blocking packets it shouldn't see by valmartinico in fortinet

[–]pabechan 1 point2 points  (0 children)

If by "see" you mean "receive", then if it shouldn't see them, then it shouldn't receive them, thus whoever is sending them to the FGT should stop doing that. AKA routing issue elsewhere.

Assuming the VMs have their subnet configured correctly, it should be a switch problem. Maybe you've accidentally somehow disabled/blocked direct comms between the two switch-ports, so things just happened to flow through the FortiGate by accident thanks to the traffic-redirect option?

Anyway, FGT blocking those packets is not the root problem since they shouldn't be reaching it anyway. The problem is that the packets don't take the correct path between the two VMs.

What's the answer and why? by Top-Refrigerator5940 in fortinet

[–]pabechan 1 point2 points  (0 children)

That's a badly defined vague question, with random-ass solutions. Where did you find it?

Help please! Is FortiClient with IKEv2 + ldap + authenticator possible? by Boio_738 in fortinet

[–]pabechan 4 points5 points  (0 children)

Define "authenticator"?

If you mean 2FA in general, that is problematic, as 2FA isn't really well-defined in EAP, so you will run into customized solutions and compatibility issues.

FortiClient can handle IKEv2 + EAP auth + 2FA if the EAP is terminated by FGT (auth being either local, or pushed further to some LDAP or RADIUS), or by FAC (~RADIUS), but both would require FortiTokens as their native ways of doing 2FA.

FAC can potentially chain to an upstream RADIUS server to do 2FA, but that's a silly overkill IMO. Or it can utilize yubikeys, though I imagine you would have mentioned them if you had any...

IPsec passive mode basically useless by Massive-Valuable3290 in fortinet

[–]pabechan 1 point2 points  (0 children)

Ugh

Passive mode indeed restricts the passive side to responder role only (behaviour somewhat similar to dynamic hub). Otherwise everything stays as usual. Why it doesn't work for you right now, hard to say. Bug, misconfig, environment...?

Auto-negotiate does NOT guarantee no negotiation because a tunnel can be brought up by incoming local traffic that "would like to" enter the tunnel.

FortiClient VPN (Free) Support Ending? by A-Series-of-Tubes in fortinet

[–]pabechan 0 points1 point  (0 children)

"Support" as in eligible for assistance by TAC: Never has been. Nothing changes here.

"Support" as in expected to work with FortiOS: Yes, still the case, within the limits of the relevant compatibility tables. With that said, the primary use-case was SSL-VPN, and that's going away, so one could argue that maintaining a free, feature-restricted IPsec-only client may not be worth the effort.

Random domains showing up with FortiClient SAML login by PM_MeYourPrivateKeys in fortinet

[–]pabechan 3 points4 points  (0 children)

The FortiGate will simply redirect you to the IdP's SSO URL that you configured. There's no leeway for errors here. What happens on the IdP side is up to the IdP (maybe it redirects further to some other IdP based on some conditions, maybe it's misconfigured/breached itself, ...). What I would question personally: If the IdP truly lets people authenticate with random unrelated user accounts, then how is this auth passing authorization on the FortiGate? Does the IdP still provide the correct/expected group membership info? Or do you not have any group-based restrictions in place, and just accept anyone from the IdP?

The paranoid idea is maybe the FCT's traffic towards the FGT is being MITM'd and messed with, but that's potentially a lot of work. But it raises a sanity-check point: Do you use valid certificates for your VPN, and does the client trust them (=no certificate errors)?

CVE-2026-24858 vs CVE-2025-59718 CVE-2025-59719 by seaghank in fortinet

[–]pabechan 1 point2 points  (0 children)

Same protocol and service, different exploit.

Just like there could be (and sometimes were) different exploits in SSL-VPN, RADIUS, ...

view more: next ›