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.