HTTPS Timeout

Hello Krisztián Révész ,

Thank you for reaching out to the community, Sign in to the command-line interface (CLI) and choose option 4. Device Console.

Then check the tcp-est-idle-timeout under the show advanced-firewall. for (Could not associate packet to any connection.) ----> Invalid traffic events.

Besides you can also check the HTTP response_timeout, under the  show http_proxy. You can try increasing the default values, with the following command:
set http_proxy response_timeout
<1-2147483647> default is 60 

Hi Vivek Jagad 

Thanks for your reply.

I have changed the tcp-est-idle-timeout to 21600 and the http_proxy response_timeout to 3000 but it's still the same.

I don't know if it should work in this case, but if I add a bypass-stateful-firewall-config from the source_host to the dest_host even tracert stops working.

Create and download a packet capture : https://support.sophos.com/support/s/article/KB-000037007?language=en_US
To understand the packet flow and the handshake between the src and dst !

I have created a PCAP from the client to the problematic webpage

Thanks for sharing the PCAP Krisztián Révész , In the PCAP, once the 192.168.X.X sends a client hello there is not server hello from 160.46.X.X, can you check the communication with the different or alternate ISP if possible just to validate ?

Also try to toggle the following options under the advance firewall:
Midstream Connection Pickup : off
TCP Seq Checking : on
TCP Window Scaling : on
TCP Appropriate Byte Count : off
TCP Selective Acknowledgements : on

Options which are off try to toggle on and those on try to toggle them off and then check 

Well, the previous PCAP came from our secondary router (where they can't reach the page). Now I have created another PCAP on our main router where the traffic from the secondary site reaches the public web. I've also included a test from the working main site too. I know it's the same ISP but there is a huge different in the PCAP. 

Which router should I try those suggestions? On the problematic secondary site, right?

Yes on the problematic site, and yes as you can see there is a difference | considering the previous PCAP and current PCAP | I would also suggest you to reduce the mss value on the WAN interface ! at least to 1360 

I made those modifications you recommended at the secondary site, but it looks the same for me.

I will reduce the mss value later this day, because the router says it may delete the configurations of the port, and I don't want the company to loose all the VLANs and IP's on the main gateway during work.

Hi!

We have managed to solve the issue.

We had to run the following command on the VLAN running on the WAN interface, and it solved the issue without removing any configuration from the port.

iptables -t mangle -A POSTROUTING -o ***WAN.VLAN*** -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

Thank you for your valuable feedback Krisztián Révész cheers, glad reducing the mss helped resolve the reported issue.