Fortinet NSE4 FortiGate Security

💻 Concrete example — the FG-60F that halved its throughput the day IPS was enabled

Ticket: A branch FG-60F benchmarked at near line rate during acceptance testing. A week after the security team attached an IPS profile to the outbound policy, users report slow transfers and the dashboard shows CPU pinned at 80% — with no change in traffic volume.

Walk: 1) Nothing is broken: acceptance testing measured plain forwarding, which the NP offloads in hardware, and the new profile moved those sessions onto the CPU/CP path. 2) Confirm it rather than assume it — diagnose sys session list on an affected flow shows the session no longer carrying an offload state, because a session handed to IPS or a proxy cannot be NP-offloaded end to end. 3) The fix is scoping, not disabling: inspect what deserves inspection. Keep IPS on the policies carrying user web and server traffic, and let bulk, already-encrypted, internal backup traffic match a separate policy with no profile so it stays on the fast path.

Verify: Re-run the transfer and watch get system performance status: CPU drops back and the inspected policies still log UTM events. The datasheet number you were benchmarking against was the firewall throughput figure — the IPS and "threat protection" figures on the same datasheet are several times lower, and those are the ones that apply now.

💻 Concrete example — the FQDN address object that works for half the users

Ticket: Finance needs access to a SaaS portal. You create an FQDN address object for portal.vendor.example, reference it as the destination in a narrow allow policy, and it works from your test PC. Finance reports it works "sometimes" — and for some users, never.

Walk: 1) An FQDN object resolves on the FortiGate, using the FortiGate's own DNS, and caches the answer for the record TTL. The SaaS is behind a CDN handing out different addresses per client and per region, so the address your firewall learned is frequently not the address the client connected to. 2) Confirm the shape of the failure before changing anything: the denied sessions land on the implicit deny, which does not log by default — turn on violation-traffic logging and the drops appear, all to addresses your object never resolved. 3) Replace the FQDN object with the ISDB (Internet Service Database) entry for that service where one exists: it carries the vendor's full published ranges and is updated by FortiGuard instead of by one DNS answer. If there is no ISDB entry, an address group of the vendor's documented prefixes beats a single FQDN.

Verify: Every finance user reaches the portal, and the implicit-deny log stops filling with that destination. Re-check the other three match fields while you are there: a schedule still in the old time zone and a custom service pinned to the wrong port produce exactly the same "the policy exists but nothing matches" symptom.

💻 Concrete example — a blocked download that looks like a network outage

Ticket: Helpdesk escalates: "the file-share site just times out, there is no block page, so it must be the ISP." The security team insists antivirus is working. Both are right.

Walk: 1) Check the UTM logs first — the AV engine did fire and blocked the file. What the user did not get was an explanation. 2) That is the flow-vs-proxy difference: flow-based inspection scans the stream as it passes and, when it has to stop a transfer mid-flight, the connection dies in a way browsers render as a timeout or reset. Proxy-based inspection buffers and reconstructs the object first, so it can cleanly return a replacement message — the branded "blocked by your administrator" page. 3) There is a detection difference too, and it points the same way: only proxy mode extracts archives, so a zipped sample that flow mode streams past gets caught once the file is reassembled. 4) Switch the inspection mode to proxy on that policy — the user-facing web and mail paths — and leave high-volume internal traffic in flow mode.

Verify: Repeat the download: the browser now shows the FortiGuard replacement page naming the detection, the UTM log entry carries the same policy ID, and support stops receiving "the internet is broken" tickets for blocked content. Bundle the profiles you just settled on into a security profile group so the next policy inherits the same posture instead of drifting.

💻 Concrete example — a partner SFTP that allow-lists one IP while you have two WAN links

Ticket: A payments partner allow-lists your primary WAN address, 203.0.113.10. Nightly SFTP uploads succeed for weeks, then start failing intermittently — always with a connection refused at their end, never a local error. Your site gained a second WAN link and SD-WAN load balancing a fortnight ago.

Walk: 1) The general outbound policy NATs to the outgoing interface address, so whichever WAN link SD-WAN picks decides the source IP. Half the uploads now leave as 198.51.100.10 and the partner drops them. 2) Do not solve this by pinning all traffic to one link — that throws away the second circuit. Solve it for that one flow. 3) Create a one-to-one IP pool holding 203.0.113.10 (one-to-one maps the internal host to a dedicated external address and preserves the source port, rather than overloading many hosts onto one address). 4) Add a narrow policy — source = the SFTP server object, destination = the partner's address, service = SSH/SFTP, NAT = that IP pool — and place it above the general outbound rule, or first-match sends it straight back down the old path.

Verify: Log & Report → Forward Traffic shows the upload session with the translated source reading 203.0.113.10 on every run, and the partner's failures stop. For the wider audit question — "which internal host was behind this public IP and port at 02:14?" — overload PAT makes that hard, which is exactly what fixed port range and port block allocation pools are for: deterministic, traceable mappings per internal host.

💻 Concrete example — an LDAP group that authenticates users but matches no policy

Ticket: You add an Active Directory LDAP server and a remote user group mapped to CN=VPN-Users. Test users authenticate successfully — the login is accepted — but the identity-based policy never matches and they get no access. Other users in the same OU work.

Walk: 1) Separate the two halves: authentication (does the password check out?) and group lookup (is this user in the group the policy names?). The first is clearly fine. 2) Test them together from the CLI with diagnose test authserver ldap <server> <user> <password>, which returns both the auth result and the group memberships the FortiGate actually sees. The failing users come back authenticated, with VPN-Users absent. 3) The cause is nested groups: those users are members of CN=Branch-Staff, which is itself a member of VPN-Users. A plain member lookup does not walk the chain. 4) Fix it in the LDAP server object — either point the group match at the nested structure AD exposes for recursive membership, or flatten the membership so the users are direct members. While you are in there, check the bind type and base DN: a regular bind with too narrow a base DN produces the same empty-group result.

Verify: Re-run diagnose test authserver ldap: the group now appears in the returned list, and the policy matches on the next login. Move the server to LDAPS on 636 if it is still on 389 — a simple bind on 389 sends the credential in the clear — and add FortiToken 2FA for anything reachable from outside.

💻 Concrete example — contractors and employees who need very different doors on the same IP

Ticket: The company hires a contractor team for a six-month project. They need one internal ticketing web app and nothing else, on their own unmanaged laptops. Employees already use the existing full-access tunnel portal. The quick answer — add the contractors to the existing group — would hand them a routed path into the corporate LAN.

Walk: 1) Give them a separate door, not a separate box. Create a portal with web mode only, tunnel mode disabled, carrying a single HTTPS bookmark to the ticketing app. 2) Expose it as its own realm so the URL path itself distinguishes the two populations (https://vpn.example.com/contractors) while both share one public IP and listening port. 3) Map the contractor group to the contractor portal in the authentication/portal mapping — the mapping, not the login page, is what decides which portal a user lands in. 4) Write the firewall policy from ssl.root to the app server only, sourced on the contractor group. Web mode still needs a policy; "clientless" limits the protocols, not the need for a rule.

Verify: A contractor logging in at the realm URL sees one bookmark and can reach one host; the same account at the employee realm is rejected. An employee is unaffected. Because nothing was installed on the contractor machines, offboarding is deleting the group membership — there is no client left behind holding a configuration profile.

💻 Concrete example — a tunnel that authenticates and then dies at phase 2

Ticket: A new tunnel to a partner's non-Fortinet firewall shows the IKE gateway established, then never passes traffic. The partner insists their side is configured "exactly as agreed". The IPsec monitor shows the phase 1 up and no phase 2 selectors.

Walk: 1) Run the one command that matters: diagnose debug application ike -1 with diagnose debug enable, then bounce the tunnel. 2) Read the failure text rather than guessing — a proposal problem reports no matching SA proposal, and it names the phase, so you immediately know phase 1 succeeded and phase 2 did not. 3) The mismatch is PFS: your phase 2 has Perfect Forward Secrecy on with DH group 14, theirs has PFS off. PFS is negotiated in phase 2 and generates fresh keying material independent of phase 1, so it must match exactly on both ends — and it is easy to miss because phase 1 already worked. 4) Agree one setting and apply it on both sides. If the debug had instead shown mismatched selectors, the fix would be the other phase 2 classic: proxy IDs, where one peer proposes the specific subnets and the other proposes 0.0.0.0/0 — the tunnel comes up and drops traffic that falls outside the agreed selector.

Verify: diagnose vpn tunnel list shows a phase 2 SA with incrementing encryption and decryption counters in both directions — counters moving one way only is its own diagnosis, pointing at the return path or a missing mirror policy. Turn the debug back off with diagnose debug disable; an IKE debug left running on a busy device is a real load.

💻 Concrete example — a tunnel failover that sends branch traffic out to the internet in clear

Ticket: A branch has a primary IPsec tunnel to HQ and a backup tunnel over a second circuit. During a planned failover test, internal 10.0.0.0/8 traffic does not switch to the backup — it leaves via the branch's default route toward the internet, where it is dropped by the upstream ISP. The traffic was meant to be encrypted.

Walk: 1) The static route pointing 10.0.0.0/8 at the primary tunnel interface is withdrawn when the tunnel drops, which is correct behaviour. With that route gone, the next best match for 10.0.0.0/8 is the default route. 2) Two things are missing. Add a route for 10.0.0.0/8 over the backup tunnel interface with a higher distance, so it only installs when the primary route is gone. 3) Add a blackhole route for 10.0.0.0/8 with a distance higher still. Now, if both tunnels are down, internal traffic is discarded locally instead of following the default route out of the building — the difference between an outage and a data leak. 4) Make failure detection active: enable DPD (dead peer detection) so the tunnel is declared down promptly rather than staying nominally up with a dead peer behind it.

Verify: Re-run the test: get router info routing-table all shows the 10.0.0.0/8 route move to the backup interface within the DPD interval, traffic keeps flowing encrypted, and with both tunnels administratively down it hits the blackhole and stops. A policy-based VPN could not have been built this way — with no virtual interface there is nothing to route over, which is the practical reason route-based is the production default.

💻 Concrete example — an IPS signature that takes a production application offline

Ticket: Ten minutes after IPS is enabled on the server policy, an internal line-of-business application stops working for everyone. The instinct in the room is to remove the IPS profile and investigate later.

Walk: 1) Do not disable IPS estate-wide to fix one application — you would trade a single broken app for an unprotected network. Find the signature first. 2) Log & Report → Intrusion Prevention, filtered to the application server, names the exact signature, its severity, and the policy ID that triggered it. It is a high-severity signature for an exploit against a product you do not run, matching a pattern this app's own protocol happens to produce — a textbook false positive. 3) Narrow the exception to the smallest thing that works. Best: an exempt entry for that signature scoped to the application server's source/destination, so the signature stays active everywhere else. Acceptable while you confirm: set that single signature's action to monitor. Never: strip the profile from the policy. 4) Note what the signature action default means for the rest — each signature uses the vendor-recommended action, which is why a freshly enabled profile can block without you choosing to block anything.

Verify: The application recovers, the IPS log keeps recording the pattern for the exempted pair without acting on it, and every other signature is untouched. Apply the same "narrow the exception" reflex to AV: if a large legitimate file trips the oversize limit, adjust that limit in protocol options for that policy rather than turning scanning off — and remember to add any non-standard ports there, or the traffic passes uninspected without ever appearing as a block.

💻 Concrete example — a wildcard exception that quietly matches nothing

Ticket: Marketing needs one social platform that the Social Networking category blocks. You add a URL filter allow entry for *.facebook.com, type Wildcard, action Allow. The block page still appears when users go to facebook.com.

Walk: 1) Precedence is not the issue: the URL filter is consulted before the FortiGuard category rating, so a matching allow entry would win. The entry is simply not matching. 2) *.facebook.com matches subdomains — www.facebook.com, static.facebook.com — and not the bare apex facebook.com that users type. Add both the apex and the wildcard, or use a pattern that covers both. 3) Scope the exception rather than granting it globally: put the allow entry in a web filter profile attached only to the marketing policy, so the category block stays in force for everyone else. 4) If the requirement is "access, but not all day", reach for a quota instead of an allow — a per-category time or volume allowance per user, blocking on exhaustion until the period resets.

Verify: A marketing user reaches the site by both names; a user outside that policy still gets the block page. Two related behaviours worth getting right at the same time: warn lets a user proceed after acknowledging a notice while block does not, and category lookups need an active FortiGuard subscription plus working DNS — when FortiGuard is unreachable, check the profile's behaviour for unrated traffic before assuming the filter is simply off.

💻 Concrete example — the banking portal and the update client that break the day deep inspection goes live

Ticket: Deep inspection is rolled out with the CA certificate pushed by GPO, and browsing works cleanly. Two things break immediately: finance cannot reach the corporate banking portal from the managed browser, and Windows Update starts failing on every machine — with errors that do not look like certificate warnings.

Walk: 1) This is not a trust-distribution failure; the GPO worked, which is why ordinary sites are fine. It is certificate pinning: these clients ship with the expected certificate or issuer baked in and reject the FortiGate's re-signed certificate by design. No amount of CA distribution fixes that — a pinned client is supposed to refuse. 2) The tell is the error style: a pinned app fails with a generic connection or update error rather than a browser trust prompt, which is why these get misfiled as network faults. 3) Add exemptions to the SSL inspection profile for the affected destinations — by FQDN, address, or whole category, and start from the FortiGuard recommended exemption list, which already covers the common pinned and sensitive services. 4) Exempt the finance and health categories as policy, not just as a fix: it avoids decrypting genuinely sensitive personal traffic, which is a privacy and often a legal position as much as a technical one.

Verify: Banking and Windows Update work again, general browsing is still decrypted and inspected, and the exempted destinations appear in the logs as bypassed rather than blocked. For anything you only need to categorise — not scan — certificate inspection remains the right tool: no decryption, no CA requirement, no pinning breakage, and no visibility beyond the domain.

💻 Concrete example — an investigation that runs out of history after three days

Ticket: Security asks for the traffic history around an incident six weeks ago. The FortiGate is logging to local disk and the oldest entry available is four days old. Nothing was misconfigured; nothing was deleted.

Walk: 1) Disk capacity is finite and logs rotate oldest-first. Find what is consuming it: a policy with Log Allowed Traffic → All Sessions on a high-volume internal path — enabled for a troubleshooting session months ago and never turned back off — is generating an entry per session and crowding out everything else. 2) Set that policy back to logging security events only, or to session end rather than every session, keeping full logging on the paths that actually warrant it. 3) Apply severity thresholds per destination so each one keeps what it is for: everything of consequence to the central collector, warnings and above locally, debug only while you are actively watching. 4) Fix the real gap — long-term retention does not belong on the firewall. Forward to FortiAnalyzer (or a syslog/SIEM target) where six weeks is routine and the reporting lives. Local disk then becomes the short buffer it should always have been.

Verify: A week later, disk history covers a useful window again and the collector holds the full record. Know what each destination costs you: memory logging is fast and volatile — a reboot erases it — disk persists but rotates and wears, and only an external collector gives retention and cross-device correlation. Enable log rate limiting so a single noisy event cannot flood the buffer.

💻 Concrete example — a failover users called an outage, on a cluster that worked perfectly

Ticket: A planned failover test is declared a success: the secondary takes over in about a second and browsing is unaffected. Meanwhile the database team reports dropped connections, and a large file transfer restarted from zero. The cluster did exactly what it was configured to do.

Walk: 1) Failover moved the traffic; it did not move the sessions. Without session pickup, the new primary has an empty session table, so every established flow is unknown and gets dropped. 2) Short-lived HTTPS connections hide this completely — the browser opens new ones and nobody notices — while long-lived TCP sessions (database connections, SSH, SFTP, large transfers) die visibly. That asymmetry is why the test "passed". 3) Enable session pickup so the session table is synchronised between cluster members and established flows survive the takeover. 4) Budget for it: synchronisation is continuous traffic on the heartbeat link, which is an argument for two dedicated heartbeat interfaces rather than one shared with anything else.

Verify: Repeat the test with a long-running SSH session and a transfer in flight: both survive, and diagnose sys ha status shows the roles swapped cleanly. Be precise about what HA does and does not cover — FGCP synchronises configuration and (with pickup) sessions, but both members must run the same firmware and hold matching licences, and in active-active mode some inspection work stays on the primary rather than being shared.