1 of 1 people found this helpful
PM me your Grant number and I'll open a ticket for you. I want you to send me audits and tcpdumps. I believe what is happening is the firewall is sending extraneous FINs or RSTs here which causes your client to FIN/ACK the connection. It is similar to something I just read about in another issue.
The firewall decrypts the traffic via the SSL rules then hands it off to the ACL rules. The rules look for a matching application. HTTP has ports TCP/80 and SSL/443. The SSL/443 here means "This application might travel over 443 and be SSL-encapsulated so you may want to decrypt it" (basically). The rules see that this is SSL/443 traffic so it matches the HTTP application and then takes the actions that are specified in the HTTP Application Defense set in that Application Defense group for that rule (virus-scanning, etc.). If you wanted to ONLY allow decrypted HTTPS inbound you would do 'Override Ports' on the HTTP application and take out the TCP/80 part, so we'd only be looking for SSL/443 traffic. That way you would not allow inbound HTTP/80 via your decrypting/scanning HTTPS ACL rule.
You have to use HTTP in your ACL rule, not SSL/TLS(HTTPS) (since it is no longer HTTPS right now, it's been decrypted). That is how I understand how this works. Page 209 of the 8.2.0 Admin Guide has a good explanation of decrypting inbound SSL and how to make your rules.
Thanks, sliedl. I have been using the SSL/TLS app all this time, so I'm guessing that means I've had reduced security as it would not be looking for specifically HTTP traffic, but anything that is or was SSL encrypted. I just made a test rule for just our company for this traffic using the HTTP Application. I want to see if this helps with the SSL errors in the log. If not, I'll look at getting you all that data you requested.