|
As a workaround, disabling and enabling the Syslog Server fixes the issue however, this is not the feasible method.
Check if the traffic to the Syslog Server IP is leaving via the WAN interface instead of the IPSec tunnel:
diagnose sniffer packet any "host <Syslog Server IP>" 4 0 l
If yes, clear the existing session:
diagnose sys session filter list
diagnose sys session filter src <Fortigate_source_IP>
diagnose sys session filter dst <Syslog_Server_IP>
diagnose sys session filter list
diagnose sys session clear
Reason for this Issue:
When a FortiGate has an active route for a private subnet (RFC 1918), the traffic will be forwarded via that interface. When that interface (IPSec/LAN) goes down, the route will be removed from the routing-table and the traffic will be sent out via the default route.
In the session list output, that session will have a 'dirty' flag. To avoid the issue in the future, there are two options.
- It is possible to enable 'snat-route-change' to allow the session to use the new route on the IPsec tunnel, once available. See this article for more details: Technical Tip: Using 'SNAT-route-change' to update existing NAT session after routing change (e.g. a...
- It is also possible to create a blackhole route for the Syslog Server IP via IPSec Tunnel Configure Blackhole.
Example:
Syslog config:
config log syslogd setting
set status enable
set server "10.190.5.1"
set port 514
set source-ip "192.168.210.1"
end
In this example, the traffic is leaving out via wan1 instead of VPN:
FGT# diagnose sniffer packet any 'host 10.190.5.1' 4 0 l
interfaces=[any]
filters=[host 10.190.5.1]
0.118169 wan1 out 192.168.210.1.8778 -> 10.190.5.1.514: udp 1072
0.118176 wan1 out 192.168.210.1.8778 -> 10.190.5.1.514: udp 906
0.118183 wan1 out 192.168.210.1.8778 -> 10.190.5.1.514: udp 830
It is possible to use the syslog server port number as well to sniff the traffic. In this example, port 514 was used:
FGT# diagnose sniffer packet any 'port 514' 4 0 l
Clearing the existing session:
diagnose sys session filter src 192.168.210.1
diagnose sys session filter dst 10.190.5.1
diagnose sys session clear
After clearing the session:
FGT# diagnose sniffer packet any 'host 10.190.5.1' 4 0 l
interfaces=[any]
filters=[host 10.190.5.1]
0.118188 VPN1 out 192.168.210.1.8778 -> 10.190.5.1.514: udp 934
0.118195 VPN1 out 192.168.210.1.8778 -> 10.190.5.1.514: udp 905
0.118203 VPN1 out 192.168.210.1.8778 -> 10.190.5.1.514: udp 838
0.118208 VPN1 out 192.168.210.1.8778 -> 10.190.5.1.514: udp 914
To fix this effectively, do the following:
- Review the Syslog Configuration to ensure the Server IP and other details are correctly entered.
- Disable NPU Offload in IPsec VPN Tunnel and ASIC Offload in Firewall Policies of that IPSec VPN. To learn more about NPU Offload and ASIC offloading to ways to disable them, refer to this article:
Technical Tip: FortiGate Disable Hardware Acceleration
- Check the working traffic via Sniffer or Flow Debug using the Syslog Server IP and its port.
Note:
The same behavior is observed even when multiple syslog servers are configured on the FortiGate if the route to all of the syslog servers uses the same IPsec tunnel.
Related articles:
Technical Tip: Prevent RFC 1918 (LAN subnets) network traffic from exiting the WAN interface
Technical Tip: Syslog server over IPSEC VPN and sending VPN logs
Technical Tip: How to configure syslog on FortiGate
|
