Description
This article describes how to enable the creation of a TCP session on the firewall without checking for a SYN packet.
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 the asymroute was disabled, the specific TCP flow would be dropped because it did not 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.
Scope
FortiGate, CLI: tcp-session-without-syn.
Solution
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)
end
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 user 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.
Example:
- The initial session creates session-00000600 and then timeouts:
id=13 trace_id=164 msg="vd-1 received a packet(proto=6, 10.200.1.11:1838->10.200.1.2:23) 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"
- The server replies after the timeout, session-00000601 is created but the policy is not present - drop:
id=10500 trace_id=165 msg="vd-1 received a packet(proto=6, 10.200.1.2:23->10.200.1.11:1838) 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"
- The user 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, 10.200.1.11:1838->10.200.1.2:23) 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"
Since this feature may possibly introduce security issues, besides activating it on the system settings, it also has to be enabled for each individual firewall policy:
config firewall policy
edit <policyid>
set tcp-session-without-syn <all/data-only/disable>
end
all: Enable TCP session without SYN.
data-only: Enable TCP session data only.
disable: Disable TCP session without SYN.
The recommendation is only to enable this feature on specific firewall policies allowing the interesting traffic.
