quarantined email release fails

Hi Adrie,

No issue reported yet. Check in the smtp.log when you release the quarantined mail, do you see any errors? 

"Releasing has recently gone wrong on my macos Sierra machine." Did you mean that the emails are releasing perfectly through a Windows system?

Thanks

I wouldn't know, I do not have access to a windows PC. 

What I know is that, on the same macos machine, Firefox and Chrome are working.

Cheers. Adrie

Did you try a Google on stop chrome from redirecting to https?

Cheers - Bob

I haven't tried it yet. The thing is this is happening to all of our users who use Chrome on their personal PCs. They are so many I can't manually apply that Chrome fix to every one of them. 

I was looking for a fix on the UTM side of things, so that way the problem will be fixed for everyone. 

This suggestion is an experiment, and I give it a 10% chance of success.  In Webserver Protection, define a Real Server on "Internal (Address)" as HTTP (not HTTPS) using the port you've configured for the Quarantine Report.  Next, define Virtual Servers on "Internal (Address)" and "External (Address)" that use HTTPS on the same port.  Please report your results.

Cheers - Bob

Thanks for your suggestion! But, unfortunately, I don't have a WebServer Protection license so I can't access that feature. I only have a Network Protection and Email Protection license on my UTM.

Your reseller can get you a 30-day trial license for Full Guard so that you can test this.  Full Guard costs less than the combination of any three of the five subscriptions included.

Cheers - Bob

We have the same problem as described in the 1st post

attempting to release a quarantined mail item from the digest fails with

Safari can’t open the page “https://<fqdn>:3840/release.plc?proto=smtp&amp;cluster_id=0&amp;message_id=1ezWqw-0004mt-9G&amp;size=9707&amp;whitelist=0” because Safari can’t establish a secure connection to the server “<fqdn>”.

this is true of both Safari and Firefox on Mac 10.12.6

the link in the digest is

http://<fqdn>:3840/release.plc?proto=smtp&cluster_id=0&message_id=1ezWqw-0004mt-9G&size=9707&whitelist=0

NB http

our device is UTM 9.508-10

Gary

I think it is a DNS michmash rather than browser

The browser reports an SSL error

from your PC can you ping utm.hiddendomain.com please? What is the result?

Yes we can ping the fqdn from both internal and external utm interfaces, both return the same, correct IP. There is no problem with the DNS.

On clicking the release link utm http daemon log has this

Yes we can ping the fqdn from both internal and external utm interfaces, both return the same, correct IP. There is no problem with the DNS.

On clicking the release link utm http daemon log has this

I said from your PC, not UTM

testing the fqdn with openssl

prosserg@ITRoom-Mint ~ $ openssl s_client -connect utm.<fqdn>:3840
CONNECTED(00000003)
140409629832864:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:795:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 295 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

The utm has no virtual server configured for SSL on port 3840, yet the utm is causing the browser (I'm now using Firefox on Linux) to switch from http to https

BUT as previously noted, the same release link works fine on an iPhone (Safari)

Gary

Of course that is what I was doing and reporting, from a PC inside the network and from a PC outside the network. I was confirming that DNS is correct.

Test the Host configuration as I said before.
You are entering in loopback. And you didnt mentioned your IPHONE Connection 3G or wifi

If You are from outside you can release the email from your external IP, from inside from your internal
Hope you are clear on tha

Oldeda

iPhone works fine on wifi and on 3G

utm httpd: 192.168.15.138 - - [27/Mar/2018:13:24:26 +0100] "GET /release.plc? <----internal device

utm httpd: 85.255.237.84 - - [27/Mar/2018:13:25:19 +0100] "GET /release.plc? <----external device

You say 'you are entering in loopback' - I appreciate you are trying to help, but that phrase doesn't make sense to me. 

You say test this configuration

Name:  utm
Type:   Host 
Ip4 Address: 192.168.2.1 (your internal interface IP) 
DHCP: No DHCP Server
DNS Settings: utm.hidden-domain.com (your FQDN that is equal in Quarantine Configuration Hostname)

so what definition do you propose for my other internal networks (5 in total) ?

G

Internal Network Address 192.168.15.138 for all 5 internals, because you can reach this IP from all internal networks. 

Oldeda

can you explain exactly what you meant by 'a loopback' effect ?

I still don't understand why a non-ssl client request to the utm on port 3840 is converted to ssl (on the same port) for SOME but not all clients, thus generating the error I've reported.

Gary

Because you may have some NAT rules for WAN interface, waf or web filter. You are hitting wan address i think

Maybe

but on click release link

web filter - nothing in its log

waf - nothing reported in its log

nat rules - we have 2 which relate to the external IP matching the fqdn I have cited

there is nothing in the web server log of GEORGE_SECURED indicating 'release' requests are being directed there - not surprising since HTTP = port 80, while release request is for port 3840

Gary

Gary, I don't understand - are clients in the same subnet treated differently?  How do you know that some aren't switched from HTTP to HTTPS - is it possible that they're using a different browser or ???

Are you using split DNS so that the FQDN resolves to the Internal IP inside you LANs and to the External IP outside?  If you're not, I would replace those two NAT rules with:

1. DNAT : Internet -> {Group of HTTP & HTTPS} -> External (WAN) [VPN_MyPortal] (Address) : to GEORGE_SECURED
2. Full NAT : Any IPv4 -> {Group of HTTP & HTTPS} -> External (WAN) [VPN_MyPortal] (Address) : to GEORGE_SECURED

Of course, if you have only one LAN on Internal, I would use "Internal (Network)" instead of "Any IPv4" in the second NAT rule.  Also, check out #5 in Rulz.

Cheers - Bob