Firebox Denying Traffic: HTTPS Invalid Protocol
Firebox T40
Version 12.7.1.B644848
We replaced a failed network device relating to Car Wash equipment. Device is same model # as previous. It's assigned IP: 10.11.17.129. We had no Firewall Policies in place for previous device. However, device is being blocked by Firewall communicating with external server. Receiving the following in Traffic Monitor:
2022-06-08 16:35:08 Deny 10.11.17.129 72.78.XXX.XXX https/tcp 1057 443 Trusted External ProxyDrop: HTTPS invalid protocol (HTTPS-proxy-00) proc_id="https-proxy" rc="594" msg_id="2CFF-0007" proxy_act="Default-HTTPS-Client" length="0"
2022-06-08 16:35:08 Deny 10.11.17.129 72.78.XXX.XXX https/tcp 1057 443 Trusted External HTTPS Request (HTTPS-proxy-00) proc_id="https-proxy" rc="548" msg_id="2CFF-0000" app_id="0" app_cat_id="0" proxy_act="Default-HTTPS-Client" action="drop" sent_bytes="64" rcvd_bytes="0" tls_version="SSL_0" tls_profile="TLS-Client-HTTPS.Standard" sig_vers="18.060"
Please let me know if additional information is needed. Any thoughts or suggestions would be much appreciated.
Thank you!
Shellie
Comments
Add a HTTPS packet filter From: 10.11.17.129 To: Any-external
Also, you should do the free upgrade to 12.7.2 Update 2 - the Cyclops Blink remediation version.
Thanks for info and timely response Bruce. Should Packet Filter be above default HTTPS-proxy policy?
Shellie
Yes.
And it will normally get put there automatically.
Thank you sooo much Bruce. Your solution resolved issue. Appreciate the time and guidance sir!
Shellie
My pleasure
@Bruce_Briggs
We too are having the same issue after installing our Firebox M290. Can you confirm if the packet filter option is still the recommendation? We are running on the latest firmware.
2025-03-12 10:21:28 Deny 192.168.1.215 xxx.xxx.xxx.xxx https/tcp 20828 443 Trusted External ProxyDrop: HTTPS invalid protocol (HTTPS-proxy-00) proc_id="https-proxy" rc="594" msg_id="2CFF-0007" proxy_act="Default-HTTPS-Client" geo_dst="IRL" length="0"
2025-03-12 10:21:28 Deny 192.168.1.215 xxx.xxx.xxx.xxx https/tcp 20828 443 Trusted External- HTTPS Request (HTTPS-proxy-00) proc_id="https-proxy" rc="548" msg_id="2CFF-0000" app_id="0" app_cat_id="0" proxy_act="Default-HTTPS-Client" action="drop" geo_dst="IRL" sent_bytes="77" rcvd_bytes="0" tls_version="SSL_0" tls_profile="TLS-Client-HTTPS.Standard" sig_vers="18.359"
Yes, if you really need/want to allow access to the destination.
Some software sends packets out TCP port 443 which is not HTTPS - thus the deny from the HTTPS proxy.
Thanks @Bruce_Briggs.
So a simple packet filter with these settings will do the job? - would this need to go at the top of the Firewall Policies once created?
That policy would allow ALL HTTPS traffic from 192.196.1.215 to any external IP addr.
My preferred policy would be To: the specific external IP addr or the FQDN of the that IP addr. From: could be just from a single IP addr or Any-trusted, as desired.
Normally Fireware will put this policy above any existing HTTPS policy.
Great, thanks Bruce.
Can I ask what the difference is between a simple packet filter rule like this and one where SNAT action is involved?
The From: field is the key. The From: field indicates whether a policy is an incoming one or an outgoing one from the perspective of the firewall interface involved.
SNAT is used for incoming connections from the Internet to an internal resource, such as a web server.
You don't use SNAT for outgoing connections from internal devices.
Thanks Bruce, got it.
I've put the packet filter in place and made sure it is above the other HTTPS policy.