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

  • 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
  • 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
  • I will suggest to test it with internal IP. I mean put in Quarantine Configuration your internal IP 192.168.x.x
    Edit the link in the email 192.x.x:3840 and you will be able to see Sophos logo with the explanation email released or not.

    Next problem must be that WAF Protection is handling all request for utm.local.com, regardless the port 3840
    Try to put another A record in DNS zone. I cannot test it because I dont have WAF enabled. GEORGE_SECURE is redirecting to https. I am 90% sure

  • 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

  • there is no log record in GEORGE_SECURE for requests to port 3840 - anyway its not listening on that port so will drop not redirect to https

    I can't simply have spam releases via an internal IP since our clients will be both internal and external

    btw - external requests work

    IF waf protection is handling port 3840 that suggests a problem in its internals

    the immediate issue for diagnostics is the lack of logging of requests to the utm via port 3840 - without that we don't know what's actually happening

    Gary

  • I dont see any logic have WAF and DNAT rules for web services
    Just for test
    LOGOUT from UTM and edit the host file in your PC. Put there the hostname of spam release with internal ip. 
    Flush your PC DNS. And click the link after

Reply Children