This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

quarantined email release fails

Releasing has recently gone wrong on my macos Sierra machine.

Tried it with Safari, Firefox and Chrome but all fail:

Safari:
Safari Can't Open the Page "https://<fqdn>:3840/release.plc?proto=smtp&mp;cluster_id=0&amp;message_id=1c2X06-0006pM-MV&amp;size=3469&amp;whitelist;0" because Safari can't establish a secure connection to the server "<fqdn>".

Firefox:
Secure Connection Failed
An error occurred during a connection to vgk.rcan.nl:3840. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

 

Chrome:
This site can’t provide a secure connection
<fqdn> sent an invalid response
Try running Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR

 

Update:

Now, a day later I found out that Safari is redirecting the http://<fqdn>:3840 to a https request. Odd. anyone experiencing similar issue?

 

Adrie



This thread was automatically locked due to age.
Parents
  • 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

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • 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

  • 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.

  • Thanks for the tip, but...

    Please explain what you mean by "Probably I know the answer." What IS the problem and why is this an answer ?

    Gary

  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • Bob - I'm also confused

    it seems none of the available utm logs are recording what's going on, so we have no definitive report

    from what I've seen a truly external client can release 

    I think it must be some kind of 'trombone' effect - all internal clients see the fqdn as a public IP....

    The fact that internal clients get an SSL error is also confusing since AFAIK none of our waf, dnat, firewall or web filtering rules are configured to redirect to ssl. In fact none of our rules cite port 3840  

    Gary

     

     

  • That's an indication that replacing the two NAT rules with the ones I've suggested might resolve your issue.  The alternative is split DNS as described in Accessing Internal or DMZ Webserver from Internal Network.

    I suspect the SSL error is a byproduct of the real problem.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Bob

    in attempting to set up the NAT rule #1 you suggest

    we do use split dns although in fact its superfluous since all dns sources resolve the relevant fqdn to the same IP (an external interface of the utm)

  • Bob

    but we are dealing with port 80 and 443 requests in our dnat rules

    meanwhile the release request is for port 3840

    why is that being ignored by the utm - firewall, waf, web filtering whatever ?

    G

  • You're right that the release is done on a different port, so the repaired NAT rule doesn't make a difference.  See #5 in Rulz to understand why you got the error message.

    If you have DNAT and WAF, see #2 in Rulz to understand that the DNAT causes traffic to bypass WAF (reverse proxy).  See the link in my previous post to understand when you need Full NAT instead of a DNAT.

    Oldeda is right - the best solution is split DNS where resolution inside your LAN is to the local IP, not the external address where you have nothing to handle port 3840 traffic from inside your LAN.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Bob

     

    I get your advice. And maybe I have to swallow it and move all our dns to the utm via interface based host definitions.

    Meanwhile our current subnets, dhcp, dns config works fine considering we have a single utm and so for resilience we use ISP dns (via forwarders) for some subnets like visitor wireless where no internal hosts should be available, or lan based dns servers for subnet specific services, or in two cases an AD domain.

    Its currently a config that works for all except, and then only recently, in one case (and only for some internal clients) - ie the spam release.

    The bit of angst I feel is that the ssl error I've reported seems to come from the utm itself simply because either

    - it doesn't have an ssl capable listener on port 3840

    - the utm is redirecting non-ssl requests to ssl; I note you say this is a 'side effect' of NAT rules - really ? Actually we can't tell as there is no relevant logging (AFAIK).

    Since the default hostname for spam release is the utm itself (with an ssl cert defined, either self signed or uploaded) why is the utm release url coded as http not https ? 

    Gary

  • This morning I changed the dns record* for utm.<fqdn> from its external interface to my PC's relevant subnet interface

    * on our local bind server

    Then, from my pc on that subnet, I ping / dig utm.<fqdn> which comes back with the IP of the internal interface.

    I try release link - get same ssl error as previously stated. The utm http daemon log has

    2018:03:29-10:41:13 utm httpd: 192.168.2.157 - - [29/Mar/2018:10:41:13 +0100] "POST /webadmin.plx HTTP/1.1" 200 484
    2018:03:29-10:41:14 utm httpd: 192.168.2.157 - - [29/Mar/2018:10:41:14 +0100] "POST /webadmin.plx HTTP/1.1" 200 485
    2018:03:29-10:41:15 utm httpd: 192.168.2.157 - - [29/Mar/2018:10:41:15 +0100] "\x16\x03\x01\x02" 404 -
    2018:03:29-10:41:15 utm httpd: 192.168.2.157 - - [29/Mar/2018:10:41:15 +0100] "\x16\x03\x01\x02" 404 -
    2018:03:29-10:41:15 utm httpd: 192.168.2.157 - - [29/Mar/2018:10:41:15 +0100] "\x16\x03\x01" 404 -
    2018:03:29-10:41:15 utm httpd: 192.168.2.157 - - [29/Mar/2018:10:41:15 +0100] "\x16\x03\x01" 404 -
    ...

    1st two lines is my PC connected to utm.<fqdn>:4444
     

    A little later I also found this in the same log

    2018:03:29-10:55:14 utm httpd: 192.168.15.138 - - [29/Mar/2018:10:55:14 +0100] "GET /release.plc?proto=smtp&cluster_id=0&message_id=1f0oKC-0001Z8-D9&size=37561&whitelist=0 HTTP/1.1" 200 452
     
    .15.138 that's a mobile device on our visitor subnet - the utm provides dhcp for that subnet; the dns servers are stated as those of our ISP ie the release link points to an external interface of the utm.