Skip to main content
MartinGmail
MartinGmail
New Member
February 18, 2015
Solved

Drops a package that should not drop by policy.

  • February 18, 2015
  • 4 replies
  • 17863 views

 

  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.

 

 

    Best answer by vjoshi_FTNT

    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.

    4 replies

    jcamacho
    jcamacho
    New Member
    February 18, 2015

    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.

    MartinGmail
    MartinGmailAuthor
    New Member
    February 18, 2015

    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
    rdumitrescu
    New Member
    February 19, 2015

    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

    MartinGmail
    MartinGmailAuthor
    New Member
    February 19, 2015

    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
    Staff
    vjoshi_FTNT
    Staff
    February 19, 2015

    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
    Staff
    ashukla_FTNT
    Staff
    February 19, 2015

    replay packet(allow_err)

     

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

    vjoshi_FTNT
    Staff
    vjoshi_FTNTAnswer
    Staff
    February 19, 2015

    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.

    Terms & ConditionsAccessibility statement