Drops a package that should not drop by policy.

[Martín]

  Hi, here is my policy in a 200B (see attachment)

Feb 18 12:26:40 192.168.x.x date=2015-02-18,time=12:27:55,devname=FG200B3910604xx,device_id=FG200B3912603xx,log_id=00 38000007,type=traffic,subtype=other,pri=warning,vd=root,src=192.168.x.x,src_port=51488,

src_int="portX",dst=200.40.28.16 8,dst_port=443,dst_int="portY",SN=57905425,

status=deny,policyid=8,dst_country="Uruguay",src_country="Reserved",

service=HTTPS,proto=6,duration=18,sent=0,rcvd=0,msg="replay packet(allow_err), drop"

i dont understand why drop this packet? Can you tell me about msg="replay packet(allow_err), drop" ?

Thanks

Martín.

[jcamacho · Accepted solution]

Hi.

Your policy is number 10, the one which is blocking the traffic is number 8. Policy number 10 must be above number 8 in order to make this one be applied first.

Regards.

[ashukla_FTNT · Accepted solution]

replay packet(allow_err)

I believe this means the packet sequence number was out of the window range so firewall dropped it.

[jcamacho · Accepted solution]

Hi.

Your policy is number 10, the one which is blocking the traffic is number 8. Policy number 10 must be above number 8 in order to make this one be applied first.

Regards.

[Martín]

Hi, this is policy 8:

Policy 8.jpg

(SSL authentication)

But, can't match here !! Because Port9(inside) - To - Port6 (internet)

This is wrong

[rdumitrescu]

Hi Martin, Just to be sure that is not an misunderstanding.....

In the first post you attach a capture from GUI ... the '10' is referred to the policy ID or to the policy Seq. ? The debug indicate that the traffic is dropped by the policy ID 8. "status=deny,policy id=8" So, try to understand if policy seq.10 is the policy id 8. To see the policy ID in GUI you must add the field or you can just see the edit number in CLI.

Regards

[Martín]

rdumitrescu wrote:

Hi Martin, Just to be sure that is not an misunderstanding.....

In the first post you attach a capture from GUI ... the '10' is referred to the policy ID or to the policy Seq. ? The debug indicate that the traffic is dropped by the policy ID 8. "status=deny,policy id=8" So, try to understand if policy seq.10 is the policy id 8. To see the policy ID in GUI you must add the field or you can just see the edit number in CLI.

Regards

Hi dumitrescu, you are right I was refered to policy id by GUI, that is not the same from CLI. I don't know why.

thanks.

[vjoshi_FTNT]

martin.germano wrote:

rdumitrescu wrote:

Hi Martin, Just to be sure that is not an misunderstanding.....

In the first post you attach a capture from GUI ... the '10' is referred to the policy ID or to the policy Seq. ? The debug indicate that the traffic is dropped by the policy ID 8. "status=deny,policy id=8" So, try to understand if policy seq.10 is the policy id 8. To see the policy ID in GUI you must add the field or you can just see the edit number in CLI.

Regards

Hi dumitrescu, you are right I was refered to policy id by GUI, that is not the same from CLI. I don't know why.

thanks.

It should be the Sequence number and not the actual ID.

On the GUI, Firewall policies will be displayed by default with the column 'Sequence' and if I am not wrong '10' should be sequence number.

- To confirm the actual ID, you can add the column 'ID' on the GUI under Firewall > Policy > Right click on the columns and select the ID

[ashukla_FTNT · Accepted solution]

replay packet(allow_err)

I believe this means the packet sequence number was out of the window range so firewall dropped it.

[vjoshi_FTNT · Accepted solution]

martin.germano wrote:

  Hi, here is my policy in a 200B (see attachment)

[attachImg]https://forum.fortinet.com/download.axd?file=0;120491&where=message&f=policy.jpg[/attachImg]

Feb 18 12:26:40 192.168.x.x date=2015-02-18,time=12:27:55,devname=FG200B3910604xx,device_id=FG200B3912603xx,log_id=00 38000007,type=traffic,subtype=other,pri=warning,vd=root,src=192.168.x.x,src_port=51488,

src_int="portX",dst=200.40.28.16 8,dst_port=443,dst_int="portY",SN=57905425,

status=deny,policyid=8,dst_country="Uruguay",src_country="Reserved",

service=HTTPS,proto=6,duration=18,sent=0,rcvd=0,msg="replay packet(allow_err), drop"

i dont understand why drop this packet? Can you tell me about msg="replay packet(allow_err), drop" ?

Thanks

Martín.

" replay packet(allow_err), drop " This message is part of the TCP sequence checking The anti-replay CLI command allows you to set the level of checking for packet replay and TCP sequence checking (or TCP Sequence (SYN) number checking). All TCP packets contain a Sequence Number (SYN) and an Acknowledgement Number (ACK). The TCP protocol uses these numbers for error free end-to-end communications. TCP sequence checking can also be used to validate individual packets. FortiGate units use TCP sequence checking to make sure that a packet is part of a TCP session. By default, if a packet is received with sequence numbers that fall out of the expected range, the FortiGate unit drops the packet. This is normally a desired behaviour, since it means that the packet is invalid. But in some cases you may want to configure different levels of anti-replay checking if some of your network equipment uses non-RFC methods when sending packets. Configure the anti-replay CLI command: config system global set anti-replay {disable | loose | strict} end You can set anti-replay protection to the following settings: • disable — No anti-replay protection. • loose — Perform packet sequence checking and ICMP anti-replay checking with the following criteria: • The SYN, FIN, and RST bit can not appear in the same packet. • The FortiGate unit does not allow more than one ICMP error packet through before it receives a normal TCP or UDP packet. • If the FortiGate unit receives an RST packet, and check-reset-range is set to strict, the FortiGate unit checks to determine if its sequence number in the RST is within the un-ACKed data and drops the packet if the sequence number is incorrect. • strict — Performs all of the loose checking but for each new session also checks to determine of the TCP sequence number in a SYN packet has been calculated correctly and started from the correct value for each new session. Strict anti-replay checking can also help prevent SYN flooding. If any packet fails a check it is dropped.