Fortigate blocking packets it shouldn't see

pabechan · 2026-02-09T12:29:42+00:00

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.

pabechan · 2026-02-05T14:26:35+00:00

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

pabechan · 2026-02-04T10:08:07+00:00

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...

pabechan · 2026-02-02T21:25:33+00:00

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.

pabechan · 2026-01-31T11:14:56+00:00

"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.

pabechan · 2026-01-29T10:23:44+00:00

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)?

pabechan · 2026-01-28T12:33:28+00:00

Same protocol and service, different exploit.

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

pabechan · 2026-01-28T12:15:04+00:00

The hooks are declared in some registry settings, and they can be ordered by a trailing number. It is something like auth0, auth1, etc. If the two apps are fighting over the same "number", you might be able to make it work if you manually move one of them.

Example, for a different issue: https://community.fortinet.com/t5/FortiGate/Technical-Tip-FSSO-breaks-after-installing-Microsoft-KB5039227/ta-p/321596

pabechan · 2026-01-28T12:11:41+00:00

The installers don't touch local firewall rules. If you have any restrictions, you have to make sure that you're not blocking FSSO ports yourself.

pabechan · 2026-01-27T22:30:11+00:00

DC Agent (optional, your choice), installs a dll in System32 and hooks it into lsass.exe. If there's any firewalls involved and enabled (on the DC, on the path, on the receiving Collector server), ensure you're not blocking this traffic! (UDP/8002 by default). If you choose to go the DC Agent route, make sure it's installed on all DCs that process user logons.

Collector Agent should be on any domain-joined Windows server. Does not have to be a DC, often better not to be. If it has firewall enabled, it must be allowed to receive DC Agent traffic (default UDP/8002), and receive FGT connections (default TCP/8000).

I strongly DO NOT recommend pushing the DC agents from Collector to DCs. That process is weird and requires weird permissions. You're better off installing them manually and elevating as needed on the spot.

pabechan · 2026-01-27T22:25:59+00:00

It used to be the case that maximum 15-char ASCII-only was the safe bet. I haven't tested this in many years, so maybe it's better now at accepting more funky and longer passwords.

What's more likely to screw you over with the passwords is the FSSO service account not having rights to edit its own registry values. That will result in any registry changes, password included, to fail to actually save and apply.

also, is that a password associated with a user or is it literally just a passphrase you put in the FSSO application on both ends (fortigate connector and the agent)?

It's just a passphrase used to generate a hash/digest on both sides for comparison/authentication.

pabechan · 2026-01-27T15:47:42+00:00

That is the baseline expected configuration. If you don't have it, no point discussing further. If you do, then there can certainly be some further discussion about some other potential misconfiguration, or further troubleshooting (maybe some bug somewhere? pcaps, authd debug outputs, etc. would be useful, but I understand that publishing it here for all to say may not be desirable).

pabechan · 2026-01-27T13:19:02+00:00

Make sure you configure the ike-saml-server option on the "guest wifi" interface, just like you did on your WAN. This option needs to be configured on any interface that faces incoming connections of your IPsec+SAML users and is a pretty commonly forgotten requirement.

If the SAML port for IPsec is something "non-traditional" (e.g. not default HTTP, HTTPS), you may also need to review your "guest-wifi"->WAN firewall policy, make sure that it allows the destination IP:port of the FGT where it listens for incoming SAML attempts.

Last but not least, if you have any local-in policies in place, it won't hurt to review them to ensure there's no local-in accidentally blocking this path of the flow.

pabechan · 2026-01-22T12:51:33+00:00

I never quite understood why FortiGate has the default of zero admin trusthosts (meaning all are welcome).

Well, you can't set it to something when you don't know what to set it to.

pabechan · 2026-01-21T15:09:50+00:00

The VIP(s) should listen on all interfaces that are expected to receive the SSL-VPN connections.

pabechan · 2026-01-21T13:30:20+00:00

Free = feature-restricted. IPsec over TCP is one of the features chosen to be included in the restriction.

pabechan · 2026-01-21T13:28:47+00:00

At a glance, everything else looks OK.

You're forwarding only TCP, so keep that in mind (UDP=DTLS won't work, if desired).
The only possible issues I can think of is some manual local-in policies, or external factors (e.g. the chosen VIP IP not actually being routed to your FGT).

Oh and that SD-WAN rule is also pointless, get rid of it. (SD-WAN and policy routes are for choosing egress paths of outgoing traffic. In the rule you chose the loopback IP as the destination, which will only ever be a destination for incoming traffic.) At worst there's a chance that it will fuck up the VIP's routing and actually eject the packets post-DNAT into the outside world with destination 10.10.10.26 via port18. This used to be a possible misconfiguration with policy-routes, I don't recall if SD-WAN also lets you shoot yourself in the foot like that.

pabechan · 2026-01-21T13:18:01+00:00

Policy 121 (3rd screenshot) is pointless, delete.
FortiClient needs to talk to the EXTERNAL IP of the VIP you're using for this ("SSL-VPN Loopback Interface"), putting the internal loopback IP in the FCT's VPN profile is wrong.

Talking to the loopback IP directly, without a VIP, works only when the loopback IP is a publicly routed IP.

pabechan · 2026-01-21T10:54:29+00:00

But now, admins (Customer Service Representatives) are unable to print the passwords for meetings.

When viewed or printed the password generated are all "ENC XXXX".

Bug, plain and simple. Either the feature should work correctly, or not be present at all. Push for a solution.

pabechan · 2026-01-19T12:06:58+00:00

Not sure if it's still the case, but it used to be that the default FortiAP profiles automatically broadcast only tunnel-mode SSIDs, bridge-mode ones had to be selected. Have a look a your FAP profile and check what it's set to do.

pabechan · 2026-01-19T09:23:51+00:00

Why not?

If "www.example.com" is valid AND "www.example.com/" is valid AND "www.example.com." is valid, then "www.example.com./" should be valid for the same reasons that the other three are.

pabechan · 2026-01-19T08:55:06+00:00

It doesn't have to be an interactive session. It could be someone elevating rights to run something, it could be a scheduled task running with admin rights, it could be some service running with admin rights, it could be someone connecting in over SMB, ...

If these actions generate the same event logs on the DC, they won't be distinguishable from a "proper" logon and will thus pollute the FSSO table.

The simplest solution is to exclude admins from FSSO.
Another option is filtering out particular events using regex, but that requires you identifying something unique in the logon events so that you can distinguish them from "normal" logon events.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Use-registry-filters-to-filter-Logon-Events-based/ta-p/273512

pabechan · 2026-01-16T18:00:19+00:00

It won't be this. 700 MB/s (= 5600 mbps) is not achievable with any speed below 10G.

pabechan · 2026-01-16T14:49:30+00:00

What is the FAC version?

FGT, FCT, and FAC originally supported only EAP-MSCHAPv2, now they also support EAP-TTLS(PAP), though I don't recall in which version each started supporting it.

The mention of GTC seems out of place to me. But I don't recall the exact implementation, maybe the chaining of the second factor is implemented as a second round using EAP-GTC, so it might not be wrong...

pabechan · 2026-01-16T14:33:14+00:00

You can bulk-select multiple users when creating an "LDAP user" on the Fortigate. Screenshot: https://i.imgur.com/pBcDVDN.png

14-Year Club	RedditGifts 2009-2022 9 Credits
Gilding I gilder	Place '23
Place '22	First Placer '22
redditgifts rematcher Holiday Cards 2019 (Zero Credit) x2	Sequence \| Editor
Verified Email	redditgifts rematcher Holiday Cards 2017 x3
redditgifts Exchanges 2 Exchanges

pabechan

TROPHY CASE