Introduction

This guide walks you through the full initial setup from factory default to a hardened, production-ready state, with security best practices baked in throughout.

What You'll Need

Before you power on the device, make sure you have the following:

• FortiGate 40F unit and power adapter (or similar model)

• RJ-45 Ethernet cable (for initial management access)

• A laptop or workstation with a browser and SSH client

• Your ISP connection details (static IP, PPPoE credentials, or DHCP — whatever applies) (if you're setting this up as your border firewall)

• A Fortinet support account (to register the device and activate licenses - not required if you want to run trial licenses and a VM)

• FortiCare and FortiGuard subscription details (UTM bundle or individual licenses)

• Your planned IP scheme for the internal network (not super required, you can use 192.168.1.0/24 doesn't really matter for this demo)

Step 1: Physical Setup and Initial Access

Connect your management workstation to port 2 (or any LAN port, typically 2–5 on the 40F) with an Ethernet cable. The WAN interface is port 1 — leave that unplugged until the initial configuration is complete. This is an important security practice: never connect an unconfigured firewall to the internet.

The FortiGate 40F ships with the following defaults:

• Management IP: 192.168.1.99

• Default credentials: username admin, no password

• HTTPS GUI: https://192.168.1.99

• DHCP server: Enabled on LAN, serving the 192.168.1.0/24 range

Set your workstation to a static IP in the 192.168.1.x range (e.g., 192.168.1.10, subnet mask 255.255.255.0) and open a browser to https://192.168.1.99. Accept the self-signed certificate warning — you'll replace this later.

Security note: Modern browsers will aggressively warn about the self-signed cert. This is expected on first access. Don't save an exception permanently — once you've configured a proper FQDN and certificate, this warning goes away. Realistically you don't need a proper FQDN and certificate for management, but if you want to make it very clean, do that!

Step 2: First Login and Firmware Update

Log in with admin and a blank password. FortiOS will immediately prompt you to set a new admin password.

Password requirements for production:

• Minimum 12 characters

• Mix of uppercase, lowercase, numbers, and special characters

• Do not reuse passwords from other devices

• Store it in your password manager or documentation vault immediately

Once logged in, the setup wizard will launch. You can run through it, but for MSPs and experienced engineers, it's often cleaner to dismiss it and configure manually so you know exactly what's been set.

Check and update firmware first — before anything else.

Navigate to Dashboard > Status and note the current FortiOS version. Then go to System > Firmware & Registration and check for updates. As of this writing, FortiOS 7.6.x is the current stable branch for the 40F. Always run a supported, non-EOL firmware version. The current FortiOS recommended by Fortinet is here: https://community.fortinet.com/fortigate-3/technical-tip-recommended-release-for-fortios-116639

Compatibility Note: Fortigate has stopped allowing SSLVPN on smaller models. Make sure you're ready to use IPSEC if you update to the latest!

Security note: Fortinet regularly patches critical CVEs (FortiOS has had several high-severity vulnerabilities in recent years). Running outdated firmware is one of the most common attack vectors on perimeter devices. Patch before you deploy, and schedule recurring maintenance windows for ongoing updates.

After upgrading, the device will reboot. Log back in.

Step 3: Register the Device and Activate Licenses

Go to Dashboard > Status > License Information and register the unit using your Fortinet support account. You'll need the device serial number, which is on the bottom label and in the dashboard.

Registration enables:

• FortiGuard threat intelligence updates (antivirus, IPS signatures, web filter databases)

• Technical support entitlement

• Firmware access

If you have a FortiCare bundle or UTM subscription, activate the licenses here. For MSPs managing multiple clients, FortiManager and/or FortiCloud make this process scalable.

Best practice: Don't skip licensing. Running a FortiGate with expired FortiGuard subscriptions means your IPS signatures, web filter categorizations, and AV definitions are stale. That's a NGFW with the "Next-Gen" stripped out. May as well bring back out the trusty Linksys DDWRT box...

Step 4: Hostname, Time, and Basic System Settings

Navigate to System > Settings.

Set the following:

Hostname: Use a meaningful, site-specific name (e.g., FGT-ClientName-Site01). This matters for syslog correlation and FortiManager inventory.

Timezone: Set the correct local timezone for the deployment site. Accurate timestamps are critical for log analysis and incident response. Don't skip this part!!!! It's often missed.

NTP: Enable NTP and point it to reliable servers. Fortinet's built-in NTP pool (ntp1.fortinet.com, ntp2.fortinet.com) works well, or use your preferred public servers (e.g., pool.ntp.org). Time sync is non-negotiable — certificate validation, logging, and scheduled tasks all depend on it.

Idle timeout: Reduce the admin session timeout from the default 480 minutes to something reasonable — 15 or 30 minutes is a good balance for active engineers. I've often seen clients request it pushed to 60 minutes instead if they have read-only or admin access.

Step 5: Configure WAN (Port 1)

Navigate to Network > Interfaces and click on port1 (WAN).

Configure it based on your ISP connection type:

DHCP (most common for cable/fiber residential-grade connections):

• Set Addressing Mode to DHCP

• Enable "Retrieve default gateway from server"

Static IP:

• Enter the IP address, subnet mask, and default gateway provided by your ISP

PPPoE (common with DSL or some fiber ISPs):

• Set Addressing Mode to PPPoE

• Enter your username and password

• Cry a bit because you have to still use PPPoE

Security hardening for the WAN interface:

• Administrative Access: Uncheck everything (HTTPS, SSH, HTTP, Ping) unless you have a specific, documented reason to enable it

• Never expose the management GUI to the internet through the WAN interface without a jump host, VPN, or IP whitelist in front of it

Critical security note: Leaving HTTPS or SSH enabled on the WAN interface is one of the leading causes of FortiGate compromise. Shodan and other scanners will find your device within hours of it going online. Keep management access locked to the LAN or a trusted management VLAN. If you absolutely need external access, use a local in policy (https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/363127/local-in-policy)

Once configured, you can connect the WAN cable to your ISP modem or handoff. Verify connectivity under Network > Routing and confirm a default route appears.

Step 6: Configure LAN Interface and DHCP

Navigate to Network > Interfaces and click on the LAN interface (often shown as lan or internal, depending on firmware version).

Recommended changes from default:

IP/Subnet: Change the default 192.168.1.99/24 to your planned internal subnet. Common choices are 10.x.x.1/24 or 172.16.x.1/24. Using the default 192.168.1.x range is fine functionally, but it creates issues with split tunneling in VPN scenarios and conflicts with many ISP-provided modems.

DHCP Server: Enable and configure the built-in DHCP server for the LAN:

• Set the address range (e.g., 10.10.1.100 to 10.10.1.200)

• Set the default gateway to the FortiGate's LAN IP

• Configure DNS servers — either use Fortinet's DNS filter feature or specify 8.8.8.8 / 1.1.1.1 as upstream resolvers

• Set lease time appropriately (8–24 hours for most office environments)

Administrative Access on LAN: Only enable what you actually need. HTTPS and SSH for management are reasonable. Disable HTTP — there's no reason to allow unencrypted management access. If you enabled local-in-policy above, make sure you allow for your internal network/hosts as appropriate too!

Step 7: Configure Security Profiles

This is where the FortiGate earns its "next-generation" label. Navigate to Security Profiles in the left menu.

Antivirus

Create or edit the default AV profile. For most SMB deployments:

• Enable scanning for HTTP, HTTPS, FTP, IMAP, POP3, SMTP

• Enable blocking of infected files

• Enable detection of grayware/riskware

Web Filter

Enable web filtering in flow-based or proxy-based inspection mode (flow-based has lower latency; proxy-based offers more granular control). At minimum:

• Block known malicious sites (built-in with FortiGuard categories)

• Block anonymizers and proxy avoidance tools

• Block phishing and fraud categories

Adjust content filtering categories based on the client's acceptable use policy. Document what you've enabled and why.

Intrusion Prevention System (IPS)

Apply an IPS profile to outbound and inbound policies. The default protect_client profile is a reasonable starting point for LAN-to-WAN traffic. Review and tune signatures periodically — overly aggressive IPS can cause false positives.

Application Control

Enable application control to gain visibility into what's crossing the wire. Start in monitor-only mode to establish a baseline, then move to blocking after you understand the environment's legitimate traffic patterns.

SSL/TLS Inspection

This is often skipped in SMB deployments — don't skip it. A large percentage of modern malware uses HTTPS. Without SSL inspection, your AV and IPS profiles are blind to encrypted threats.

Configure a Deep Inspection profile, install the FortiGate's CA certificate on client machines (via Group Policy or MDM), and apply the inspection profile to your outbound policy.

Note: SSL inspection requires client trust of the FortiGate's certificate. Plan this deployment carefully, especially for managed devices. Unmanaged personal devices (BYOD) may need to be on a separate policy without inspection, or require users to manually install the cert.

Step 8: Configure Firewall Policies

Navigate to Policy & Objects > Firewall Policy.

A clean policy set is easier to audit and troubleshoot. Follow these principles:

LAN to WAN (outbound): Create a policy allowing internal traffic out to the internet. Apply your security profiles (AV, web filter, IPS, application control, SSL inspection) here. Log all sessions — storage is cheap, blind spots are expensive.

WAN to LAN (inbound): By default, no inbound policy exists, meaning all unsolicited inbound traffic is denied. This is the correct default. Only create inbound rules for specific, documented, business-justified services (e.g., a VIP/DNAT rule for an on-prem mail server or remote access service). Each inbound rule should be as specific as possible — source IP restrictions, specific destination ports, and logging enabled.

Implicit deny: FortiOS has an implicit deny-all at the bottom of the policy table. Don't delete it. Enable logging on it to catch unexpected traffic patterns.

Policy hygiene best practices:

• Name every policy descriptively (e.g., LAN_to_WAN_Outbound_UTM not Policy_1)

• Add comments explaining the business justification

• Review the policy table quarterly and remove unused rules

• Avoid "any/any" policies — specify source and destination objects wherever possible

Step 9: Configure Remote Access (VPN)

For remote workers or MSP management access, configure either SSL-VPN or IPsec VPN.

SSL-VPN (web portal + FortiClient):

Navigate to VPN > SSL-VPN Settings.

• Bind to a specific interface (consider a loopback or management port rather than the main WAN - https://community.fortinet.com/fortigate-3/technical-tip-ssl-vpn-connection-to-a-loopback-interface-using-virtual-ip-176357)

• Set the listening port — changing from the default 443 or 10443 to a non-standard port adds mild obscurity, though it's not a substitute for strong auth. It's also extremely annoying to troubleshoot and adds another step for manual client setups if you don't have FortiEMS or another XML push script.

• Enable two-factor authentication — FortiToken, email OTP, or integration with a RADIUS/MFA provider. Even better if you can do SAML with Azure or similar!

• Restrict access to specific user groups

• Set idle and authentication timeout values

Create an SSL-VPN portal and a firewall policy allowing VPN users access only to the resources they need — not the entire internal network.

IPsec VPN (site-to-site):

For connecting branch offices or client sites, use IPsec with IKEv2. Use strong encryption parameters:

• Phase 1: AES-256, SHA-256, DH Group 14 or higher

• Phase 2: AES-256, SHA-256

Avoid outdated algorithms (DES, 3DES, MD5, DH Group 1/2/5). FortiOS will flag weak proposals, but verify manually.

Step 10: Harden Administrative Access

This section is often skipped in rushed deployments. Don't.

Change the default admin account

Navigate to System > Administrators. The built-in admin account cannot be deleted, but you should:

• Set a strong password (done in Step 2)

• Create a separate named admin account for each engineer who needs access (for audit trail purposes)

• Assign appropriate permission profiles — not everyone needs super-admin

Enable two-factor authentication for admin accounts

Go to System > Administrators, edit each account, and enable two-factor authentication using FortiToken Mobile, email OTP, or a RADIUS/TACACS+ server.

Restrict management access by trusted hosts

In each admin account, set Trusted Hosts — this restricts GUI and SSH login to specific source IP addresses. For MSPs, whitelist your jump host, RMM egress IP, or management VLAN. This is one of the most effective controls against unauthorized admin access. You can also use local-in-policy for this. If you do this, you prevent the ability for someone to forget adding trustedhosts to a new admin user, and opening the entire device up to the internet because of a simple mistake.

Disable unused management services

Under System > Settings > Administration Settings:

• Disable HTTP (use HTTPS only)

• Consider disabling the management GUI on the WAN interface entirely (done in Step 5)

• Enable HTTPS redirect

Replace the self-signed certificate

Navigate to System > Certificates and either import a certificate from your PKI or use Fortinet's ACME integration to generate a Let's Encrypt certificate for the management domain. A valid cert eliminates browser warnings and ensures encrypted management traffic isn't undermined by users clicking through cert errors. Your helpdesk will thank you... because if you don't do this... they're getting a lot of tickets.

Step 11: Logging and Monitoring

A firewall you can't see into is a liability.

Configure FortiCloud or a syslog server

Navigate to Log & Report > Log Settings.

For standalone deployments, enable FortiCloud (basic log storage is included with registration). For MSP environments, forward logs to a central syslog server or SIEM (Splunk, Graylog, Microsoft Sentinel, etc.) using UDP/TCP syslog on port 514.

What to log:

• Traffic logs (at minimum, log denied traffic and security policy matches)

• Event logs (admin logins, config changes, HA events)

• Security logs (IPS, AV, web filter alerts)

• VPN logs

Log level: Set to "Information" for security events. "Debug" is noisy and for troubleshooting only.

Set up email alerts

Under Log & Report > Alert Email, configure alerts for critical events: admin login failures, IPS critical detections, high CPU/memory, HA failovers.

SNMP monitoring

If your NMS (LibreNMS, PRTG, Zabbix, etc.) supports it, configure SNMP v3 (not v1 or v2c — those send community strings in plaintext) for interface monitoring, resource utilization, and uptime tracking.

Step 12: Backup the Configuration

Before going live, export a backup of the full configuration.

Navigate to System > Backup and download the config file. Store it in:

• Your documentation platform (IT Glue, Hudu, etc.)

• A secure file share or backup location separate from the device

• Source control, if your team uses it for network configs

Set an automation stitch or scheduled task to push config backups to FortiCloud or your backup destination on a regular cadence (weekly at minimum).

MSP note: For client environments, keep a copy of the decryption password if you encrypt the backup file. Losing it means losing access to the config. You can also use FortiManager to keep config downloads and change management as it can be set up to take a config file for every change it sees.

Post-Deployment Checklist

Before handing the environment over, run through this checklist:

• [ ] Firmware is current and on a supported release

• [ ] Device is registered and licenses are active

• [ ] Default admin password has been changed

• [ ] Named admin accounts created for each engineer; MFA enabled

• [ ] Trusted hosts configured on all admin accounts

• [ ] WAN interface has no management services exposed

• [ ] LAN subnet changed from default 192.168.1.x (if applicable)

• [ ] DNS configured and resolving

• [ ] NTP synced and timezone correct

• [ ] Security profiles (AV, IPS, Web Filter, App Control) applied to outbound policy

• [ ] SSL inspection configured and CA cert deployed to clients

• [ ] No unnecessary inbound firewall policies

• [ ] Implicit deny logging enabled

• [ ] VPN configured with MFA (if required)

• [ ] Syslog/FortiCloud logging enabled

• [ ] Alert emails configured

• [ ] Configuration backed up and stored securely

Ongoing Maintenance

Setup is a one-time event. Maintenance is continuous.

• Firmware: Review Fortinet PSIRT advisories monthly. Patch critical vulnerabilities within your SLA windows.

• Policy review: Audit firewall policies quarterly. Remove stale rules, document changes. This is easier said than done, but good standardization practices make this much easier.

• License renewal: Track expiration dates. Expired FortiGuard means stale threat intelligence. It can also mean your webfilter blocking all traffic because it can't access FortiGuard. Ask me how I know!

• Log review: Review security logs regularly, or ensure your SIEM has alerting that does it for you.

• Backup verification: Periodically restore a config backup to a test unit or VM (FortiGate VM is available) to verify backup integrity.

Closing Thoughts

The FortiGate 40F is a capable piece of hardware, and FortiOS is a mature platform — but the security it provides is only as good as the configuration behind it. Default settings are designed for ease of first use, not for production security. Every step in this guide moves the device from "out of the box" to "defensible."

For MSPs, consider templating this configuration in FortiManager or using FortiOS CLI scripts to speed up consistent, repeatable deployments across client sites. Consistency is security at scale.

If you have questions or want to share how your team approaches FortiGate deployments, drop a comment below.

This guide was written based on FortiOS 7.4.x on the FortiGate 40F. Interface names and menu paths may vary slightly between firmware versions.

Step-By-Step Guide

• Prepare and baseline your WAN links. Document the following for each tunnel and ISP you have coming into the Fortigate.

  • Bandwidth

  • SLA Expectations

  • Labels (if they're not labelled, LABEL IT)

    

  • Correct IP, Gateway, Subnet Mask, and any specific routes

• Test each link for ping, jitter, and throughput. You can use iperf for throughput, or speedof.me for internet speed tests.

• Create SD-WAN Zones and add members

  • Network > SD-WAN > SD-WAN Zones

  • The biggest gotcha here is if you already have some of these interfaces in use. Follow the instructions here (link TBD) to get around this issue.

  • Create a zone for internet (I label it WAN, or Internet)

    

  • Create a zone for each tunnel group (e.g. Chicago for all tunnels going from this site to the Chicago site)

    

  • Add each interface to the appropriate member (e.g. Add Comcast Internet ISP Interface to Internet SD-WAN Zone)

  • Assign the correct bandwidth values (upload and download). If you don't have these numbers, make a note to find them and update this when you get them

    

• Build realistic Performance SLAs

  • This part is SUPER important! Building unrealistic SLAs makes SD-WAN effectively useless.

  • Create SLAs for different traffic types (e.g. General Internet, VoIP, Microsoft SaaS, etc)

    

  • Use appropriate probe type (e.g. Ping is good for general internet, HTTP is good for specific software, TCP is good for VoIP or other software that may not host a web server)

    

  • Set thresholds based on real measurements. This is important! Your DSL in the middle of Wyoming will not get 5ms latency and SD-WAN should not remove the route when it goes above 10ms.

    

  • Avoid overly tight latency/jitter values. This will cause flapping, and poor user experience (and lots of tickets).

• Assign SLA participants

  • For each SLA, select which members should be tested. Keeping this at default means that ALL SD-WAN members will be tested and can affect traffic.

    

  • Don't probe links that should never carry traffic.

  • Confirm SLA status shows healthy values and modify performance SLAs as needed.

  • Come back to these metrics in a week and see if you need to tune any.

• Create intent-based SD-WAN rules

  • Match traffic by application, ISDB, or subnet

  • Use strategies aligned with business intent (whatever the users care about)

    • Best Quality -> VoIP, Teams, Zoom, etc

    • Lowest Cost (SLA) -> Bulk Traffic, Backups, or things that don't care as much

    • Maximize Bandwidth (SLA) -> General internet traffic (including your Pandora stream yes)

  • Attach the correct SLA to each rule

  • Order the rules from most specific to least specific

    

• Tune failover behavior

  • Ensure SLA thresholds reflect real-world internet variance (again... your Wyoming DSL may go up above 50ms...)

  • Enable route removal when a link is out of SLA. The main gotcha here is that if you didn't set your performance SLAs correctly, or don't have something for it to fail over to... then it'll just fail.

  • Avoid aggressive failover times that cause oscillation (and angry users)

  • Test both hard failures (link down) and soft failures (high latency/loss). If you haven't tested... then test!

• Integrate security without breaking SD-WAN

  • Keep firewall policies focused on security.

  • Keep SD-WAN rules focused on path selection.

  • Apply consistent security profiles (don't have one ISP with web filtering and the other have nothing... unless it's a business need!)

  • Ensure policy order doesn't bypass SD-WAN unintentionally

• Validate SD-WAN decisions

  • Use the SD-WAN monitor to confirm path selection for all intended traffic

  • Check SLA logs for stability. This is important as you may have flapping and not notice it!

  • Run tests! Run them again! Involve users. Your users should have a basic understanding of their business needs, so they should know what works and what doesn't. The best question is "Is this working how you expect and want it to?"

  • Simulate link degredation then have users test again

• Monitor and adjust

  • A week later, go and review hit counts on all your rules

  • Watch SLA trends and see what thresholds you need to adjust

  • Send logs to FortiAnalyzer (FAZ) or another SIEM for long-term visbility

• DOCUMENT IT

  • No really. Document it.

  • If it's not documented then you're not done yet.

Common Mistakes

• Using default SLAs without tuning thresholds

• Mixing dissimilar links in the same rule without intent.

• Not enabling app control/application identification

• Over-relying on volume-based load balancing

• Not testing soft failures and only testing hard failures (pull the cable)

Conclusion

In short: SD‑WAN stability is rarely fixed by magic—it's fixed by measurement, sensible thresholds, and careful tuning. Baseline each WAN, document everything, choose realistic SLA targets, and make your probes and failover logic reflect real user experience (not just idealized pings). When you see route flapping, don’t reflexively replace hardware—tune probe intervals, consecutive-failure thresholds, and target endpoints; label and group interfaces; and validate failover behavior with controlled tests. Finally, treat tuning as an iterative process: start conservative, monitor for a week under normal load, then tighten settings only when metrics show you can. Do this and you’ll turn “mystery disconnects” into predictable, manageable behavior.

Quick checklist to finish the job

• Baseline each link (latency, jitter, packet loss, throughput) and record SLA expectations.

• Use reliable, consistent probe targets (ISP or well-distributed public endpoints).

• Reduce sensitivity to noise: increase probe interval or consecutive-failure count before marking SLA failed.

• Tune thresholds to reflect real user tolerances (allow small jitter/brief loss).

• Label interfaces/zones and document routes, weights, and policies.

• Test failover in a controlled window and monitor for several days before finalizing settings.