HTTPS Proxy "Enable Application Control" causing errors and delay on W10 workstations
Since upgrading to a more recent firebox firmware, I have been getting a lot of "fail to get application identification information for connection" errors in the logs
After some digging, have tied it back to a HTTPS Proxy option "Enable Application Control" which seems to be causing issues with what I believe is some sort of google Google functionality (embedded in Firefox Browser and Email client), and Antivirus connections.
If its on, then the users notices this as a 15 second lag, when opening documents off websites and delivered through email
If I disable it, then no issues
Firebox is at v12.6.2 (Note - I can't find this online - only 12.5.4)
Any ideas?
Below is WatchGuard Event log while issue is happening (with local and external interface renamed) where there's a 15 sec delay between the two bolded time stamps
2020-10-20 23:03:35 Allow xx.xx.xx.xx139 172.217.165.14 https/tcp 65476 443 Trusted External_PPOE Application identified 631 128 (HTTPS-proxy-Open-00) proc_id="firewall" rc="100" msg_id="3000-0149" src_ip_nat="yy.yy.yy.yy" tcp_info="offset 5 A 3333664918 win 3104" app_id="15" app_name="Google" app_cat_id="14" app_cat_name="Web services" app_beh_id="6" app_beh_name="Access" sig_vers="18.115" geo_dst="USA" Traffic
2020-10-20 23:03:35 Allow xx.xx.xx.xx139 172.217.165.14 https/tcp 65476 443 Trusted External_PPOE ProxyInspect: HTTPS domain name match (HTTPS-proxy-Open-00) HTTPS-Client.1 proc_id="https-proxy" rc="592" msg_id="2CFF-0003" proxy_act="HTTPS-Client.1" rule_name="Default" sni="sb-ssl.google.com" cn="*.google.com" ipaddress="172.217.165.14" geo_dst="USA" Traffic
2020-10-20 23:03:35 Allow xx.xx.xx.xx139 172.217.165.14 https/tcp 65476 443 Trusted External_PPOE ProxyInspect: HTTPS content inspection (HTTPS-proxy-Open-00) HTTPS-Client.1 proc_id="https-proxy" rc="592" msg_id="2CFF-0009" proxy_act="HTTPS-Client.1" tls_profile="TLS-Client-HTTPS.Standard.2" inspect_action="HTTP-Client-Gem" server_ssl="TLS_AES_256_GCM_SHA384" client_ssl="TLS_AES_128_GCM_SHA256" tls_version="TLS_V13" geo_dst="USA" Traffic
2020-10-20 23:03:35 Allow xx.xx.xx.xx139 172.217.165.14 https/tcp 65476 443 Trusted External_PPOE ProxyAllow: HTTP Request categories (HTTPS-proxy-Open-00) HTTP-Client-Gem proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client-Gem" cats="Search Engines and Portals" op="POST" dstname="sb-ssl.google.com" arg="/safebrowsing/clientreport/download?key=%GOOGLE_SAFEBROWSING_API_KEY%" geo_dst="USA" Traffic
2020-10-20 23:03:35 Allow xx.xx.xx.xx139 172.217.165.14 https/tcp 65476 443 Trusted External_PPOE ProxyAllow: HTTP good reputation (HTTPS-proxy-Open-00) HTTP-Client-Gem proc_id="http-proxy" rc="590" msg_id="1AFF-002D" proxy_act="HTTP-Client-Gem" reputation="1" host="sb-ssl.google.com" path="/safebrowsing/clientreport/download?key=%GOOGLE_SAFEBROWSING_API_KEY%" geo_dst="USA" Traffic
2020-10-20 23:03:50 pxy 0x275a7d0-895256 fail to get application identification information for connection'-1: xx.xx.xx.xx139:65476 -> 172.217.165.14:443 [~!A rs] {R} | -1: yy.yy.yy.yy:65476 -> 172.217.165.14:443 [~!B rsa] {N}[C]', error='Bad file descriptor Debug
2020-10-20 23:03:50 Allow xx.xx.xx.xx139 172.217.165.14 http/tcp 65476 443 Trusted External_PPOE HTTP request (HTTPS-proxy-Open-00) HTTP-Client-Gem proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client-Gem" op="POST" dstname="sb-ssl.google.com:443" arg="/safebrowsing/clientreport/download?key=%GOOGLE_SAFEBROWSING_API_KEY%" sent_bytes="384" rcvd_bytes="0" elapsed_time="14.939875 sec(s)" reputation="1" reason="262189" action="allow" geo_dst="USA" Traffic
Comments
A number of site have had issues with V12.6.2 Update 1- which is why it was pulled.
I have App Control enabled on my HTTPS proxy, and I did not have this issue in V12.6.2 U1.
I am now running V12.6.2 U1 on my T20w, which I was able to install via WG Cloud.
Consider downgrading to V12.5.4, or open a support incident
Just doing that now. Thanks Bruce!
Just a follow up.. Turning App control off actually didn't solve the issue (Errors
and slowness still where there when I re-tested just a little while ago).
I had setup a firebox-db user attached to a ANY packet filter which when logged into the firebox-db user, the issue then went away
Sorry for the confusion.
Paul
PS. Have another strange issue where VPN users have access to the internet; but I can't find a policy to support this access.
I intentionally block VPN access back out to the internet as the connection is rather slow at 25Mbps/10Mbps.
A few remote machines running the (seems like hourly some days) massive windows updates, or deciding to watch 4K video through the VPN will hose the connection for hours.
Hopefully the downgrade will bring the box back to normal