Description
This article describes possible root causes of having logs with interface 'unknown-0'.
Scope
FortiGate.
Solution
There are several scenarios, which such a log message can be generated:
- When an interface (virtual or physical) status changes (add/del/up/down).
It triggers a routing table update, which flushes 'dev info of the related sessions due to re-routing.
Such sessions will later timeout if there is no following-up packet after the flush.
While they are being removed from the session table logs with the 'unknown-0' src/dst interface is generated.
- These log messages are also known to be seen when a packet comes to a FortiGate or FortiOS and can't find an existing session for it, although it is expected that it should be in place.
Below are two examples of such a scenario:
- When FortiGate receives a TCP FIN packet, and there is no session that this packet can match.
An example of such scenario can be a TCP session removed from the session table after 'session-ttl' value is expired for it.
In case the session is removed earlier than client closed it, such client may still try to use it.
As FortiGate will not expect to receive any TCP packets except TCP SYN triggering creation of a new session, all other packets will be dropped due to 'implicit deny' policy (ID 0) match and 'unknown-0' log message will be generated.
- Another valid example for such log messages is when a session is removed from the session table because the destination server closed it.
In such case, if for any reason client still sends packets related to the removed session, packets are dropped due to 'implicit deny' policy (ID 0) match and 'unknown-0' log message is generated.
In both examples, ‘No Session Match’ messages are seen in the debug flow logs.
Related article:
Technical Tip: Interface unknown-0 in traffic logs
