Note for Enterprise Environments: This configuration utilizes a secondary syslog instance (syslogd2) and a dedicated free-style filter. This guarantees that your primary logging, SD-WAN visibility, and internal traffic monitoring remain 100% untouched and fully operational.
This guide explains how to configure a FortiGate firewall to forward guest Wi‑Fi logs to an external syslog platform. It is written in a generic way so it can be used with a cloud log management platform, a SIEM, or a self-hosted syslog server. All values are placeholders and should be replaced with the parameters of the selected syslog solution.
Scope
Use this guide when FortiGate is the gateway for a guest Wi‑Fi environment and needs to forward logs to an external syslog collector. In this deployment model:
- DHCP must be configured on FortiGate.
- The captive portal may be configured either on FortiGate or on a wireless platform/controller.
- The external syslog parameters may be entered directly by the customer or provided by Cloud4Wi, depending on the project model and the selected log destination.
This guide focuses on the FortiGate side of the configuration.
Prerequisites
Before starting, confirm the following:
- Administrative access to the FortiGate firewall is available.
- DHCP for the guest network is configured on FortiGate.
- Guest traffic is traversing FortiGate firewall policies.
- The guest SSID is already operational.
- The captive portal is already working, whether it is hosted on FortiGate itself or managed through a wireless solution such as Meraki.
- The external syslog destination has been chosen, or the customer has the syslog server details available.
Information to collect
Before configuration, collect or define the following values. These values may either:
- be provided by Cloud4Wi, or
- be filled in directly by the customer when using their own log destination.
| Parameter | Placeholder | Description |
| Syslog hostname or IP | <SYSLOG_FQDN> | Preferred if the destination supports hostname-based configuration. |
| Syslog port | <SYSLOG_PORT> | For example 514, 6514, or a provider-specific port. |
| Transport protocol | <UDP/TCP/TLS> | TLS is recommended for production. |
| CA certificate file | <CA_CERT_FILE> | Required when validating a TLS server certificate. |
| Client certificate name | <CLIENT_CERT_NAME> | Required only if the syslog platform uses mutual TLS. |
| Optional location or tenant identifier | <LOCATION_IDENTIFIER> | Used only if the external receiver requires a site or tenant mapping value. |
Note: If Cloud4Wi provides the Syslog service, please ensure that the Device Names of all FortiGate firewalls are shared with Cloud4Wi so that log ingestion can be restricted to authorized devices only.
Architecture notes
DHCP on FortiGate
DHCP must be configured directly on FortiGate for the guest network. This is an important prerequisite because the firewall must remain the authoritative point for guest IP assignment and traffic visibility.
Captive portal placement
The captive portal does not have to be hosted on FortiGate. Supported models include:
- Captive portal on FortiGate
- Captive portal on a wireless controller or platform
In both cases, this guide remains valid as long as guest traffic still passes through FortiGate and the guest policies on FortiGate are the ones generating the logs.
Configuration overview
A clean deployment usually has four steps:
- Verify logging is enabled on the guest policies used by the Wi‑Fi traffic.
- Configure the secondary external syslog destination (syslogd2) on FortiGate via CLI.
- Apply a free-style filter to forward ONLY the Guest VLAN logs.
- If TLS is used, import the required certificates before enabling encrypted syslog transport.
1. Verify Logging on Guest Firewall Policies
Go to Policy & Objects > Firewall Policy, identify the policy used for guest Wi‑Fi traffic, enable Log Allowed Traffic and set it to All Sessions if full session logging is required. You do not need to disable logging on your corporate or SD-WAN policies; the filtering will be handled in the next step.
2. Configure the Secondary Syslog Destination (syslogd2)
To avoid interfering with your primary syslog/SIEM, we will configure a secondary syslog instance (syslogd2).
Using the CLI, configure the server settings using the values collected earlier:
config log syslogd2 setting
set status enable
set server "<SYSLOG_FQDN>"
set port <SYSLOG_PORT>
set format default
end
(If TLS is required, add set mode reliable and set enc-algorithm high)
3. Apply the Guest VLAN Filter
This is the most critical step to ensure that only the Guest Wi-Fi logs are forwarded to the external platform, keeping your corporate traffic private.
Replace VLAN-GUEST with the exact name of your guest network interface.
config log syslogd2 filter
config free-style
edit 1
set category traffic
set filter "srcintf VLAN-GUEST"
next
end
end
Important Note on Log Volume & FQDN Logging: The configuration above forwards all standard traffic logs (Layer 4 network connections) from the Guest VLAN. Depending on your guest network size, this can generate a significant amount of data (e.g., background app connections, DNS queries, etc.). If your compliance or business goal requires only user browsing history (FQDN/URL logging) without the underlying network noise, further advanced filtering is necessary. This involves disabling standard traffic forwarding and capturing exclusively UTM Web Filter logs.
4. Configure syslog over TLS (Optional)
If the external platform supports encrypted syslog transport, use TLS instead of plain UDP or TCP whenever possible.
Important: import certificates first Before enabling syslog over TLS, import the required certificate material on the FortiGate. Depending on the selected syslog platform, one of these models may apply:
| TLS model | Required on FortiGate | Typical usage |
| Server certificate validation only | Root CA or intermediate CA certificate | Common with cloud syslog platforms |
| Mutual TLS | CA certificate plus client certificate | Common with private or enterprise collectors |
Go to System > Certificates and import the required CA certificate first. If the selected platform uses mutual TLS, also import the client certificate and private key, then record the FortiGate certificate object name.
Validation steps
After configuration, validate the deployment in this order:
- Connect a device to the guest Wi‑Fi.
- Confirm that the device receives its DHCP lease from FortiGate.
- Confirm that the traffic passes through the expected guest firewall policy.
- Confirm that the relevant policy is generating logs.
- Confirm that the external syslog server is reachable on the required port.
- Confirm that logs are visible in the external syslog platform.
- If TLS is enabled, confirm that there are no certificate validation errors.
5. FortiGate Syslog Filtering: Web Filter Ingestion & Traffic Suppression
This guide demonstrates how to configure advanced free-style filtering on FortiGate (using primary syslogd or syslogd2) to forward exclusively Web Filter logs for a specific VLAN while suppressing high-volume Layer 4 network connection logs (traffic).
1. Configuration Steps (CLI)
Example using syslogd2 and a generic interface FortiLAN-VLANX
Execute the following commands in the FortiGate CLI to enable syslogd2 and apply the targeted filter:
Plaintext
config log syslogd2 setting
set status enable
set server "<SYSLOG_SERVER_IP>"
set port <SYSLOG_PORT>
set format default
end
config log syslogd2 filter
config free-style
edit 1
set category webfilter
set filter "srcintf FortiLAN-VLANX"
next
edit 2
set category traffic
set filter "srcip 255.255.255.255"
next
end
end
Rule 1 (
edit 1): Captures URL/FQDN browsing activity (webfilter) originating specifically from yourFortiLAN-VLANXinterface.Rule 2 (
edit 2): Suppresses standard L4 session logs (traffic) by binding the rule to the non-existent dummy IP255.255.255.255.
2. Verification Command
To verify that the active filter settings are applied correctly:
Plaintext
show log syslogd2 filter
3. Log Output Comparison
Forwarded Log Example (category webfilter) This log is generated when a user on the designated VLAN browses a website. It is successfully captured and forwarded to the syslog receiver:
Plaintext
date=2026-09-10 time=10:15:00 devname="FGVM02TM24011232" devid="FGVM02TM24011232" logid="0316013056" type="utm" subtype="webfilter" eventtype="ftnt_wf" level="notice" vd="root" policyid=1 sessionid=98765 srcip=192.168.25.45 srcport=51234 srcintf="FortiLAN-VLANX" dstip=142.250.180.206 dstport=443 dstintf="port1" proto=6 service="HTTPS" hostname="www.example.com" profile="guest-webfilter" action="passthrough" reqdesc="https://www.example.com/" url="/" sentbyte=1200 rcvdbyte=4300
Reason: Matches Rule 1 (
type="utm",subtype="webfilter", andsrcintf="FortiLAN-VLANX").
Dropped Log Example (category traffic) Standard TCP/UDP connection logs are dropped by the firewall engine and are not sent to the syslog receiver:
Plaintext
date=2026-09-10 time=10:15:00 devname="FGVM02TM24011232" devid="FGVM02TM24011232" logid="0000000013" type="traffic" subtype="forward" level="notice" vd="root" policyid=1 sessionid=98765 srcip=192.168.25.45 srcport=51234 srcintf="FortiLAN-VLAN25" dstip=93.184.216.34 dstport=80 dstintf="port1" proto=6 service="HTTP" action="accept" sentbyte=300 rcvdbyte=600 sentpkt=4 rcvdpkt=5
Reason: Rule 2 restricts
type="traffic"logs strictly to source IP255.255.255.255. Because no active host uses this address, all standard L4 session logs are effectively discarded.