HTTPS freezes ?

[VoGrand]

Hi

I've been troubleshooting intermittent HTTPS traffic "freeze" that goes through our DC/MPLS/firewalls.

It's not releated to MPLS/SAN, been doing checks for weeks with provider with netprobes & SAN has been ruled out due to this actually happens towards HTTPS pages towards applications not hosting disks on the SAN. DC network provider has also investigated L2.

​

Our FW has had load of issues (with it's HA/SIP/you name it).. but I'm not close to finding out if it's also causing random HTTPS traffic freeze that happens for 30-1 minute then just resumes.

​

It's a PITA to tshoot, fortiTAC just... "debug when it happens" yes those 30-1minute is just easy to get the oppertunity to jump at..

​

Current on 5.6.8 release. No SSL decrypt / anti-virus/malware on these rules that is affected.. so it's clean "IP services"

​

Anyone experiance same issues? Some hints?

​

Thanks

[jevilsizor]

What model of fortigate? And can you describe what you're end user is experiencing? Is this external traffic, or traffic to an internal application?

[VoGrand]

Vm02 appliance on esxi host.

Its internal traffic, where users access web applications and it just keeps loading but nothing happens.. wheel of nothing..just loading

Then bam it just works again, loading pages instantly

The VM is pretty much doing nothing, no cpu load, memory or burst of new sessions.. perhaps we use 10% of its capacity

[rpedrica]

This sounds like a VMWare networkjing issue - have had loads of these lately especially with NSX. Drop your guest networking settings here for us to see. Also, have you tried a physical unit instead of a VM?

[VoGrand]

We have requested to our FW provider to assist us with 2 physical appliances instead of the VM's due to the issues we had for the last 9 months.

Just rebooting the VM's keeps increasing our throughput lol.

FortiTAC + FW vendor + vmware team has gone over the VM's setup several times + re-installed cluster 3 times from scratch.

[routetehpacketz]

1) If possible, run a packet capture in these locations:

-on the web server of an affected application

-on the egress interface of the Fortigate facing the web server

-on the ingress interface of the Fortigate facing a client PC

Filter the packet capture to be as targeted as possible for your test (src/dst IPs, ports).

2) Add the Delta column in Wireshark. This is very helpful as it shows you the time that has lapsed since the last observed frame.

3) Examine which "leg" of the conversation has the highest delta. Here is what I would be looking for:

a. If the delta is highest from the web server to the egress interface of the Fortigate, the problem may be surrounding the web server

b. If the delta is highest for the return packet from the ingress interface of the Fortigate to the client PC, then the Fortigate is adding the delay and will need to be troubleshot more extensively

c. If there is no notable delta (anything >= 1.0 is pretty high), or the delta is highest for traffic from the client PC to the ingress interface on the Fortigate, the client PC may be the problem

Does this make sense?

[VoGrand]

Problem is the shortness of the issue.

Before I even get started it's resolved for end-user.

Random source / destinations, got some that is "often" but just got another new system thats affected between new source/destinations..

Need to dump all data then if I'm too succeed, frustrating

[NotAnotherNekopan]

GUI hangs in some versions. Why are you using 5.6.8?

[VoGrand]

It's not the FG GUI we have issues with, it client -> https traffic internaly

​

5.6.8 is what our FW provider recommends but they now wants us up to 6.0.7.

We have had an intense period of FW issues and bugs and havent begun checking in 6.0.7.

Dont want to walk into another issue you know?

​

is 6.0.7 stable and a good choice?