External HTTPS download times out through Netscreen firewall

SirNtwrk · 09-29-2005, 11:12 AM

I still have not been able to solve this one. We have a client that is trying to download files from our HTTPS server. Everyone in the world can do it except this guy. He has a SonicWall firewall with stateful packet inspection turned on. If he moves his server outside the Sonicwall or turns off SPI, the download works just fine. If not, he gets into the site and starts the download, but it only gets about 20% of the way through and then times out. Sounds like his problem, right? Unfortunately, I can direct him through our backup off-site link and he can get the file just fine. Both our primary site and backup site are using Netscreen 50 firewalls. The one at the primary site is in high availablity mode (active/passive.)

We have confimed that this is an issue with the way our primary firewall is interacting with the SPI on the Sonicwall, but cannot figure out a fix for this. We have eliminated the IIS version, permissions, SSL certificate issues, server builds, and switch types.

If anyone has seen this or anything like this, please let me know.

Thanks!

Jason Carter

SirNtwrk · 10-05-2005, 03:56 PM

In case anyone is interested in the solution here, which we finally found today, here it is:

The SonicWall firewall apparently does not have the ability to turn off stateful packet inspection as the administrator originally stated. Instead, he was turning off TCP Stateful Inspection. This is a very tight protocol that forces each packet to perform a 3 way handshake in order for it to be considered valid. Upon upgrading his firmware, this option became Strict TCP Stateful Inspection. Turning this option off meant that the establishment of the HTTPS connection would follow the 3 way handshake rules, but subsequent packets inside that session would be passed without the handshake. We have turned off the "Strict" option and everything runs well without sacrificing the security.

I still need to determine why the packets are coming in as duplicates or out of order through one firewall and not the other, but this is at least sovled for now if anyone is interested or comes across this in the future.

Thanks to everyone who at least took a look at this for trying to help.

09-29-2005, 11:12 AM	#1 (permalink)
SirNtwrk Registered User Join Date: Aug 2005 Posts: 26 OS: Win XP SP2	External HTTPS download times out through Netscreen firewall I still have not been able to solve this one. We have a client that is trying to download files from our HTTPS server. Everyone in the world can do it except this guy. He has a SonicWall firewall with stateful packet inspection turned on. If he moves his server outside the Sonicwall or turns off SPI, the download works just fine. If not, he gets into the site and starts the download, but it only gets about 20% of the way through and then times out. Sounds like his problem, right? Unfortunately, I can direct him through our backup off-site link and he can get the file just fine. Both our primary site and backup site are using Netscreen 50 firewalls. The one at the primary site is in high availablity mode (active/passive.) We have confimed that this is an issue with the way our primary firewall is interacting with the SPI on the Sonicwall, but cannot figure out a fix for this. We have eliminated the IIS version, permissions, SSL certificate issues, server builds, and switch types. If anyone has seen this or anything like this, please let me know. Thanks! Jason Carter

10-05-2005, 03:56 PM	#2 (permalink)
SirNtwrk Registered User Join Date: Aug 2005 Posts: 26 OS: Win XP SP2	In case anyone is interested in the solution here, which we finally found today, here it is: The SonicWall firewall apparently does not have the ability to turn off stateful packet inspection as the administrator originally stated. Instead, he was turning off TCP Stateful Inspection. This is a very tight protocol that forces each packet to perform a 3 way handshake in order for it to be considered valid. Upon upgrading his firmware, this option became Strict TCP Stateful Inspection. Turning this option off meant that the establishment of the HTTPS connection would follow the 3 way handshake rules, but subsequent packets inside that session would be passed without the handshake. We have turned off the "Strict" option and everything runs well without sacrificing the security. I still need to determine why the packets are coming in as duplicates or out of order through one firewall and not the other, but this is at least sovled for now if anyone is interested or comes across this in the future. Thanks to everyone who at least took a look at this for trying to help.