FortiGate Firewall Logs

FortiGate firewalls record every allowed and denied session, security (UTM) detection, VPN event and administrator action. With FortiGate's built-in remote syslog, these logs are pushed to KubeSense as they happen. They are stored with your other logs, so you can search them on the Logs page, build dashboards and alert on denied traffic or attacks.

FortiGate sends straight to KubeSense. You don't need to run any log collector, relay server or agent.

How it flows

The recommended setup keeps everything private. Logs leave the FortiGate through an encrypted IPsec site-to-site VPN and reach an internal load balancer that has no public IP address.

FortiGate firewall(s)  (your data center / branches)
   │  syslog over TCP (reliable mode), key=value format
   │  source IP from <ONPREM_CIDR>
   ▼
IPsec site-to-site VPN  (encrypted over the internet)
   ▼
Cloud VPN gateway  (AWS Virtual Private Gateway / Transit Gateway)
   ▼
Internal load balancer  <KUBESENSE_SYSLOG_IP>:<SYSLOG_PORT>   (private IP only)
   ▼
KubeSense
   │  parses every FortiGate field into a log
   ▼
Logs page

• Transport: TCP syslog in FortiGate reliable mode, so logs are not lost silently the way they can be with UDP.
• Format: FortiGate's default key=value format. KubeSense parses every field.
• Privacy: the IPsec tunnel encrypts the traffic over the internet, and the load balancer is reachable only from your network ranges.

Logs usually show up in KubeSense a few seconds after the FortiGate writes them.

Before you start

You need:

• FortiOS 7.0 or later on each FortiGate.
• An administrator account on the FortiGate with write access to Log & Report.
• A private network path from the FortiGate to the cloud network where KubeSense runs: an IPsec site-to-site VPN or a dedicated connection such as AWS Direct Connect. See Network setup.
• Two values from KubeSense. Ask your KubeSense contact for them. KubeSense sets up the endpoint on its side.

Also share with your KubeSense contact:

1. Network setup

The FortiGate must be able to reach <KUBESENSE_SYSLOG_IP>:<SYSLOG_PORT> over a private path.

AWS side (your AWS team)

1. Customer gateway. In the VPC console, go to Customer Gateways → Create. Enter the FortiGate's public WAN IP (<FORTIGATE_PUBLIC_IP>). Choose BGP with a private ASN (for example <ONPREM_ASN>), or static routing.
2. VPN gateway. Attach a Virtual Private Gateway to the KubeSense VPC. With many sites or several VPCs, use a Transit Gateway instead.
3. Site-to-site VPN connection. Connect the customer gateway to the VPN gateway. AWS creates two tunnels for redundancy.
4. Download the configuration. Choose Download configuration, vendor Fortinet, and your FortiOS version. AWS generates a FortiGate configuration with the keys and tunnel addresses filled in.
5. Return routes. In the route tables of the KubeSense private subnets, turn on route propagation from the VPN gateway (or add a Transit Gateway route) for <ONPREM_CIDR>.

FortiGate side (your network team)

1. Apply the configuration file downloaded from AWS. It creates both IPsec tunnels and their routes.
2. With static routing, add a route for <CLOUD_VPC_CIDR> through each tunnel. Give the second tunnel a higher distance so it is used only as a backup.
3. Confirm that both tunnels are up:

diagnose vpn tunnel list

In the AWS console, both tunnels should show UP.

2. Send logs from the FortiGate

FortiGate GUI

1. Go to Log & Report → Log Settings, tab Global Settings.
2. Under Log Settings:

3. Click Apply.

The GUI sets only the server address. Set the port, the TCP transport and the source IP in the CLI, as described next.

FortiGate CLI

Open Edit in CLI from the same page, or connect over SSH, and run:

config log syslogd setting
    set status enable
    set server "<KUBESENSE_SYSLOG_IP>"
    set port <SYSLOG_PORT>
    set mode reliable
    set format default
    set source-ip <FORTIGATE_LAN_IP>
end

If the port is not 514, FortiGate asks you to confirm the different port. Answer y.

Choose which logs to send

config log syslogd filter
    set severity information
    set forward-traffic enable
    set local-traffic enable
    set multicast-traffic disable
    set sniffer-traffic disable
    set anomaly enable
end

Check that logs arrive

1. Test the connection from the FortiGate:

execute telnet <KUBESENSE_SYSLOG_IP> <SYSLOG_PORT>

It should print Connected. Press Ctrl+C to close it.

2. Send a batch of sample logs (traffic, IPS, antivirus, web filter, VPN and more):

diagnose log test

3. Within a minute, the logs show up on the KubeSense Logs page with Source = fortigate.

3. Where the logs show up

FortiGate logs appear on the Logs page next to your other logs. Filter on Source = fortigate to see only them.

Kubernetes-only fields such as Namespace, Node, Container and Pod are empty for FortiGate logs.

Attributes

Every field FortiGate sends becomes an attribute, so you can filter, group and alert on any of them. The most useful ones:

Levels

A log at INFO whose action is deny, blocked, block, dropped or reset is raised to WARN, so blocked traffic stands out.

4. Useful searches

Good first alerts:

• A spike in denied traffic from one srcip.
• Any utm log with subtype = ips or virus.
• Failed admin logins (subtype = system, action = login, status = failed).

Troubleshooting

Check the current settings at any time:

get log syslogd setting
get log syslogd filter