FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Article Id 191772
Up to FortiOS v5.2, if asymmetric routing was enabled on the firewall, FortiOS could route a TCP flow without checking the SYN flag, even if a session was not present in the session list.  However this flow did not create a session and once asymroute was disabled, the specific TCP flow would be dropped because it didn't match any existing session.  For a security device operating in NAT or Transparent mode, this would disrupt all relevant sessions, which would have to be restarted.

Sometimes the firewall needs to handle long sessions, such as large data transfers or database backups, which can remain open at the endpoints but the session can be deleted from the firewall because of inactivity higher than 3600 sec (default inactivity timer).  If a packet belonging to a deleted session reaches the firewall, it will be dropped.  For this kind of scenario, disabling SYN checking in the FortiOS on a packet that belongs to an open session on the endpoints, could help avoiding such disruptions to network traffic flows, when the session becomes active again.

CLI : tcp-session-without-syn

A new feature was introduced in FortiOS v5.4 which allows the creation of a TCP session on the firewall, without checking the SYN flag on the first packet, for both transparent and route/NAT mode.  This parameter can be enabled per VDOM:
config system settings
    set tcp-session-without-syn disable|enable (disable by default)

The purpose of this new feature is to avoid disrupting existing sessions when adding/updating a security device operating in transparent mode to a working network or when long sessions are resumed after their session is deleted from the session list of the firewall.  This feature supports:
  • Session table creation even without a SYN packet
  • Session list synchronization on the slave device
  • NP offloading

Enabling the new feature will have the following results:
  • Once a TCP non-SYN packet arrives to the firewall, it will create a session
  • The session is validated against a firewall policy: if a firewall policy allows the flow it will be forwarded, if not, the flow will be blocked deny.  This means that bidirectional policies should be maintained!

For a longterm session, it may be thought that traffic will be first sent from client instead of from server.  Therefore it should be OK with unidirectional policies from client to server.

If the server is expected to send traffic to the client, both directions should be covered by a policy.  Therefore after disabling the asymmetric routing, the policies must be updated accordingly to avoid disruptions on both directions.


1) Initial session creates session-00000600 and then timeouts:
id=13 trace_id=164 msg="vd-1 received a packet(proto=6,> from port9."
id=13 trace_id=164 msg="allocate a new session-00000600"
id=13 trace_id=164 msg="use addr/intf hash, len=1"
id=13 trace_id=164 msg="drop broadcast: in: port9, out: mesh.1"
id=13 trace_id=164 msg="use addr/intf hash, len=2"
id=13 trace_id=164 msg="send out via dev-port10, dst-mac-00:09:0f:be:aa:c2"

2) Server replies after the timeout, session-00000601 is created but policy is not present - drop:
id=10500 trace_id=165 msg="vd-1 received a packet(proto=6,> from port10."
id=10500 trace_id=165 msg="allocate a new session-00000601"
id=10500 trace_id=165 msg="use addr/intf hash, len=1"
id=10500 trace_id=165 msg="Denied by forward policy check"

3) Client sends another TCP packet to the server, session-00000602 is created and flow is allowed by policy:
id=13 trace_id=166 msg="vd-1 received a packet(proto=6,> from port9."
id=13 trace_id=166 msg="allocate a new session-00000602"
id=13 trace_id=166 msg="use addr/intf hash, len=2"
id=13 trace_id=166 msg="Allowed by Policy-1:"
id=13 trace_id=166 msg="send out via dev-port10, dst-mac-00:09:0f:be:aa:c2"