quarantined email release fails

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

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

The certificate is redirecting you

Bye

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

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

A little later I also found this in the same log