Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
kanes39
New Contributor III

TCP Retransmission, out of order and duplicate

Hi Team,

 

I am looking for some advise on the logs that we are seeing on my firewall.

 

Firewall is a VM hosted in Azure.

FGT Version 7.0.11

 

Problem:

User tries to login to server that is hosted in the DMZ (Azure) using LDAP and it takes approximately 1-2 minutes to login. The LDAP server is located on a different VNET.

 

Traffic Flow:

 

VNET-DMZ -->FW (Inside) --> FW (Inside) -->VNET (LDAP).

 

There seems to be huge amount of re-transmission, duplicate and out of order packet when the user tries to attempt (capture on done on FGT). This is the reason why the delay in authentication using LDAP.

It also appears that the authentication is successful only using the service LDAP_UDP and not tcp.

 

MTU on server set to 1500, MSS 1418 can be seen on the packet capture.

 

MTU on the NIC of the FGT is set to 1500, duplex, speed and other elements has been checked.

 

Appreciate any guidance on what else I can check to understand the reason for the issue.

 

On a note the firewall logs indicates "TCP Reset" for the TCP packets.

 

Firewall rules are in place and allows communications both ways.

6 REPLIES 6
abarushka
Staff
Staff

Hello,

 

You may consider to decrease MSS to 1418 or lower (default is 1460) and check whether the issue persists:

 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Setting-TCP-MSS-value/ta-p/194518 (firewall policy)

 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Behavior-of-TCP-MSS-setting-under-system-i... (interface)

 

FortiGate
BillH_FTNT
Staff
Staff

Hi @kanes39 

 

It is easier for you when you capture the packet and save it to a pcap file, then analyze it based on Wireshark.
I think the key packet to help solve the issue is the packet that needs "retransmission." You can check this packet's details inside and outside places related to "length, MSS" to know precisely. After that, you can find the solution next.

 

Thanks/Bill

kanes39
New Contributor III

Hi BillH_FTNT,

 

I did perform the capture and investigated it via WireShark.

This is where i can see that the MSS is set to 1418.

The one very obvious differences that i can see is that the CWR is set to 1 on packets that had retransmission and 0 on packets that pass through. 

 

Thanks - Kanes

 

BillH_FTNT

Hi @kanes39 

Not only MSS, based on Wireshark, but you will also know where the packet is lost. The site makes packets lost, which will be deeply checked. I can't PM you, so if you don't mind. You can share your Wireshark files with me through mail  bhoang@fortinet.com. I will show you more things. 

 

Brs/Bill

kanes39
New Contributor III

Hi BillH_FTNT,

 

Thank you very much for the tips and the issue was caused by 2 elements:

a) Asymetric routing on Azure.

BillH_FTNT

Hi @kanes39 

You're welcome. Azure, by default, load-share traffic to customers, so asymmetric routing is very popular.

Thanks/Bill

Labels
Top Kudoed Authors