Description
This article describes the Anti-Replay option per-policy.
For information, refer to:
- Fortinet Documentation here.
- How anti-replay works and sniffer usage for testing here.
- Replay traffic scenario here.
- Configure packet replay and TCP sequence checking here.
Solution
When the global anti-replay option is disabled, the FortiGate does not check TCP flags in packets.
config system global
set anti-replay {disable | loose | strict} <-- Level of checking for packet replay and TCP sequence checking.
end
The following are the explanations for every available option in set anti-replay:
disable Disable anti-replay check.
loose Loose anti-replay check.
strict Strict anti-replay check.
This feature adds a per-policy anti-replay option that overrides the global setting. This allows to control whether or not TCP flags are checked per policy.
This is useful when you need more granular control for specific traffic that does not require TCP flags checking.
config firewall policy
edit x
set anti-replay {enable | disable} <-- Enable/disable anti-replay check. Default is enabled.
next
end
Note: The default configuration of anti-replay is enabled.
It is possible to see below the error message in the debug flow when anti-replay is enabled:
2021-06-16 08:56:19 id=20085 trace_id=1033 func=print_pkt_detail line=5622 msg="vd-root:0 received a packet(proto=6, 192.168.35.109:64154->192.168.36.5:22) from port1. flag [.], seq 4057395850, ack 800443321, win 1029"
2021-06-16 08:56:19 id=20085 trace_id=1033 func=resolve_ip_tuple_fast line=5702 msg="Find an existing session, id-00296aae, original direction"
2021-06-16 08:56:19 id=20085 trace_id=1033 func=tcp_anti_reply line=1025 msg="org dir, ack in state syn_sent, suspicious"
2021-06-16 08:56:19 id=20085 trace_id=1033 func=ip_session_core_in line=6307 msg="anti-replay check fails, drop"
In a scenario with SD-WAN and dual-hub, the options 'set anti-replay disable' and 'set tcp-session-without-syn all' are very useful.
They work together very well, when for example there is an SLA change that affects the session.
In the diagram below, there is a spoke connected to two HUBs via WAN1 and WAN2. The client established a TCP session to the server behind the HUBs.
Initially, the session is created via WAN1 and allowed on HUB1(arrow No1), if for some reason the SLA changes, then the spoke will start to use the better route via WAN2 (arrow No2). If the 'set tcp-session-without-syn' is not enabled, then HUB2 will block the incoming packets hence the session fail and timeout.
If it is enabled, then will it allow the session to be created without a new 3-way handshake, once the SLA recovers and the spoke switches back to WAN1(arrow No3), then HUB1 will drop the session/packets if the 'set anti-replay' is disabled.
Both options should be configured on HUB1 and HUB2, the reason is that the active TCP session from spoke could switch to the better-performing member.
Note: To be able to use the setting tcp-session-without-syn under the firewall policy configuration, be sure to enable this setting under the system setting. In other words, execute the following CLI commands:
config system settings
set tcp-session-without-syn enable <--- Enable it to create the tcp-session-without-syn option in the firewall policy.
end
