FortiGate 40F Initial Setup: A Practical Guide for Small Business IT & MSPs
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.
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):
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.
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!
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.
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
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:
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.
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.
