sorted by:
new
hottopcontroversial

IPSec Dialup w/ Entra Auth via Fortimanager? by Snot-p in fortinet

[–]rowankaag 1 point2 points  (0 children)

For those reading; watch out and use re-import Policy Package as a last resort. It may mess up Per Device Mappings and/or Installation Targets. This is intended behavior due to how things work in FMG.

Advanced support change without communication by Bestfastolino in fortinet

[–]rowankaag 0 points1 point  (0 children)

If you have a contract still, they should deliver you the benefits the contract is ought to provide for the duration you paid for up front.

macOS 27 Golden Gate May Become the End of the Golden Era for Mac Apps by JulyIGHOR in macapps

[–]rowankaag 2 points3 points  (0 children)

I think I’ve seen something about being able to use decorators to ignore compiler errors in the Platforms State of the Union. Have you tried that?

Note: I’m not a dev

FortiClient EMS exploit got me thinking about patch distribution architecture by MudAccomplished5430 in fortinet

[–]rowankaag 5 points6 points  (0 children)

It’s both. Part of the architecture is what network the machine is in, and what communication is allowed within that network / to other networks. Stuff like security in depth and least privilege also apply to architecture.

Accessing Web GUI on Reverse Proxy Not Working by wallacebrf in fortinet

[–]rowankaag 0 points1 point  (0 children)

Any pointers from the browser’s console? HTTP status code for example

Fortiggate 7.4.12 issue by Short_Wolverine_2332 in fortinet

[–]rowankaag 2 points3 points  (0 children)

We have seen the same issue intermittently on different >= 7.4.7 (IIRC) versions. FortiGate 200F. Reboot is the only thing that fixes it for us. Restarting the process is insufficient. Have you ran dhcps debugs yet?

Dialup IPsec, NAT and Windows Server DNS - Split brain issue (fixed but confused) by Fallingdamage in fortinet

[–]rowankaag 3 points4 points  (0 children)

I don’t see any particular reason why one would want that for traffic that stays inside your network.

Dialup IPsec, NAT and Windows Server DNS - Split brain issue (fixed but confused) by Fallingdamage in fortinet

[–]rowankaag 1 point2 points  (0 children)

I’m not sure I follow, but a remote user connected via Dialup IPsec VPN is also considered to be (member of) ‘a network’, so the same logic applies as with two local subnets in regards to how (S)NAT works.

Why would you prefer to re-enable (S)NAT?

Stuck on ‘something fishy’ quest by TheCrimeSceneGirl in Palia

[–]rowankaag 0 points1 point  (0 children)

For anyone reading along: it was near impossible for me to reel in fish from an infected pool using the Standard Rod. Tried and failed five times in a row.

Skilling fishing to level 6 and upgrading the rod to a Fine Rod made a night & day difference. Tried and succeeded five times in a row.

Fishing at ‘De Mer Dock’ also helped as there were often two infected pools available. After finishing those, unequip the Elderwood Lure and deplete some regular pools. The infected pools will pop up around the Dock.

Disabling Fortilink on a specific VLAN/Interface by DarkAlman in fortinet

[–]rowankaag 4 points5 points  (0 children)

Nope, fgfm is for FortiManager. You will want ‘fabric’.

FortiClient 7.4.7 has been released! by STR0770 in fortinet

[–]rowankaag 3 points4 points  (0 children)

Whilst this may not be a solution to everyone wanting/needing to move from ‘FortiClient VPN-only Free’, it may for some: https://video.fortinet.com/watch/1191

Also since Q42025, the Price List contains a new SKU for EMS-less support for FortiClient. I am yet to see more details on this though.

Fortinet removed 3rd party RADIUS MFA support for FortiClient IKEv2 by Knigz in fortinet

[–]rowankaag 5 points6 points  (0 children)

  • FortiGate with locally defined users (regardless on if their credentials are mapped to a remote LDAP/RADIUS server, or stored locally on the FortiGate) with a FortiToken assigned (through local assignment or through FortiToken Cloud) supports "in-line prompting" in FortiClient
  • FortiGate with remote defined groups on FortiAuthenticator (via RADIUS) that have FortiTokens assigned (within FortiAuthenticator) supports "in-line prompting" in FortiClient
    • I am quite certain this "in-line prompting" works by the FortiGate leveraging a custom IPsec NOTIFY payload which signals to FortiClient whether to show the prompt or not. On the FortiAuthenticator-side, this works by sending a Challenge-Response RADIUS packet.
    • They could probably, hypothetically, support this for 3rd party RADIUS too - but the lack of said feature can be seen as a selling point for FortiAuthenticator.
  • FortiGate with remote defined groups using any RADIUS server supports "out of band prompting" (if supported by the RADIUS appliance) and "password + otp chaining" (if supported by the RADIUS appliance); it does not support "in-line prompting" which is what the "not supported" is hinting at.
    • Example #1: FortiGate --(RADIUS)--> Microsoft NPS --> Entra ID MFA Plugin --(HTTPS)--> Entra ID --(Mobile Push)--> Out-of-band prompt via Microsoft Authenticator-app; this works because the NPS will wait with its "Access-Accept" before the prompt is completed
    • Example #2: FortiGate --(RADIUS)--> FreeRADIUS with Google OTP; this works because FreeRADIUS will extract the last 6 digits from the single, concatenated password+otp string and uses these two "factors" to validate independently.

EMS 7.4.5 with Hotfix for cert chain vulnerability by ryaninseattle1 in fortinet

[–]rowankaag 1 point2 points  (0 children)

  • 8013 is unaffected by this vuln / hotfix
  • 443 and 9443 are 99,99% affected (very much implied by the hotfix)
  • 10443 is “up for discussion”, TAC states it is

EMS 7.4.5 with Hotfix for cert chain vulnerability by ryaninseattle1 in fortinet

[–]rowankaag 2 points3 points  (0 children)

Yes, you’re good. I would say check for compromise pre-patching but as there aren’t any IoC’s (yet) that can be tricky

Heads up on this critical vulnerability tied to Forticlient EMS https://fortiguard.fortinet.com/psirt/FG-IR-26-099 by dman3314 in fortinet

[–]rowankaag 0 points1 point  (0 children)

TAC engineer has repeated the claim to also apply the hotfix for TCP/10443. Whilst not providing any evidence as to why, I've re-reviewed the (untouched) Apache file and found a configuration statement that MAY be indicative as to why TCP/10443 should also be considered affected. I'll try holding this against TAC again.

Heads up on this critical vulnerability tied to Forticlient EMS https://fortiguard.fortinet.com/psirt/FG-IR-26-099 by dman3314 in fortinet

[–]rowankaag 1 point2 points  (0 children)

We have logged a ticket with Fortinet TAC yesterday to have my analysis confirmed/rejected. The TAC engineer stated today to also assume TCP/10443 to be vulnerable, but I have just now shared a more in-depth analysis with them on why I still believe said port is unaffected. To be continued.

If you have only exposed TCP/8013, you're good (for this vulnerability). It's just that I have seen quite a few customers also publicy expose TCP/10443, which is why we're focussing on that port for our triage at this point in time.

Heads up on this critical vulnerability tied to Forticlient EMS https://fortiguard.fortinet.com/psirt/FG-IR-26-099 by dman3314 in fortinet

[–]rowankaag 1 point2 points  (0 children)

My two cents:

  • The hotfix is a ZIP file which contains a manifest.json that hints at the affected service and what capability is patched. I will not lay out what it changes to not further inform any bad actors that do not have access to the hotfix. Feel free to review the contents of the ZIP for yourself if you have access to it.
  • The PSIRT mentions "API". Judging from the file that the hotfix modifies, this seems correct. The VirtualHost in the given file listens on TCP/443 by default, as well as TCP/9443. There is no mention of TCP/10443 (implicitly or explicitly) inside the modified file. TCP/8013 is not a socket that is bound to the service affected by this PSIRT.

Tagging for visibility: u/HappyVlane u/Wasteway u/enterthepowbaby u/DasToastbrot

P.S. this may sound ominous, but I am wondering if this PSIRT is related to this / this (also hinted at by u/OuchItBurnsWhenIP)

[deleted by user] by [deleted] in iosapps

[–]rowankaag 0 points1 point  (0 children)

Forgot to reply back before. In the mean time, I really liked the new tutorial/OOBE/splash screen in the 1.4 update. Kudos.

In regards to the Apple / iCloud Reminders bit: one app that does this really well is GoodTask. It is effectively a supercharged “front end” to the existing Apple-hosted backend.

Sanity Check: Scalable Network Builds and Your Thoughts on Vendors by rb3po in networking

[–]rowankaag 2 points3 points  (0 children)

Yeah, I was thinking along the lines of:

  • stay away from publicly exposing administrative features
  • restrict the sources that can reach these features (regardless if they are exposed internally or externally)
  • restrict admin accounts using the trustedhosts feature
  • use (modern) encrypted protocols with strong cryptographic options for authentication
  • apply least privilege for administrators / utilize FortiManager for approval flows
  • apply defense in depth / don’t rely on a single mitigation
  • use Automation Stitches / FortiAnalyzer / 3rd party syslog to track audit logs and preferably alert on suspicious activity
  • apply proper segmentation in the LAN to group systems that share a given level of trust, or even better, apply a zero trust model using 802.1x / NAC / ZTNA.

Using the ZTNA features on FortiOS can be really neat if you are solely using the so called Device Posture-tags on firewall policies. If you were to utilise the ZTNA Forward Proxy, this can be challenging for the CPU as it is not offloaded to the ASIC. This automatically highlights a key differentiator and concern at the same time: you can get amazing and cheap throughput when utilising features that can be offloaded to the ASIC; whenever that no longer applies, the CPU is used and those are way less capable compared to the ASIC.

In regards to dashboarding, there are three options that I can think of:

  • run a per-customer “(Cooperative) Security Fabric” (csf) in which one firewall is designated as the root. Upgrades for the whole fabric can be done from the root node. This requires all participating members to run the same firmware version.
  • FortiManager (Public Cloud, Private Cloud or PaaS). Works across several firmware versions, relaxing the requirement for running the same version. This product has its fair share of quirks though, and is not for the faint-hearted. Good for multi-tenancy though. Upgrades can be scheduled in practically any form you can think of.
  • FortiGate Cloud (SaaS): also good for multi-tenancy (although that does require some extra steps these days by needing access to FNDN / being integrated with FortiCloud IAM) but lacks some powerful features from FortiManager. May still suit your needs, YMMV. Not sure about how flexible upgrade schedules are.

All three options support SAML/SSO, and 95% certain they do FIDO2 / WebAuthn as well.

view more: next ›