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

"Target service not allowed" error

I am relatively new to the Astaro product and in general everything is working fine, but I'm having problems with a specific WEB site.

The site references another site within a frame.   The issue is that the referring site is redirecting HTTP on port 6167 to the referenced site.  I believe this is to track the referring site.  I've added exceptions for both sites and even opened port 6167, however it still does not work for our proxy users.  They get the "Target service not allowed" error in the frame.
Can anyone provide me with information on correcting this?

Primary site is www.appliancecanada.com which refers to www.rwscheckout.com:6167.


This thread was automatically locked due to age.
  • kind a magic !! or in the moment i configured i wasn't focused, right now is working as you told me, i setup a "Filtering Options / Websites" , and i deleted the rule from the Firewall rules and still working,  i dont know why it worked before

    so, the most probably thing it was my mistake, really sorry for lose your time, at least i can now make a more clean config in the UTM, by deleting the not useful config´s

    thanks and regards

  • In my case "Web Protection / Filtering Options / Misc Settings / Allowed Target Services" worked for me to allow content to TCP port 8443. All other attempts to add URL exceptions did not work until I applied this port change.

  • Standard mode asks the browser to send all traffic to the proxy.  The proxy only allows 80, 443, and any ports added to the additional services list.   Other ports are blocked, as you have discovered.

    If standard mode is bypassed for any reason, transparent mode might be triggered, depending on your configuration.   Transparent mode only sees ports 80 and 443.  All other ports will bypass the proxy.

    Traffic that is handled by the proxy will bypass the firewall rules completely.   Traffic that is not handled by any proxy will be evaluated by the firewall rules.

    Chrome has the QUIC protocol which uses UDP 443 for TLS (primarily with Google-technology servers)  

    This traffic may evade your proxy and be processed by firewsll rules.  So QUIC may be the reason your firewall rule had some effect.

    You should block UDP 443 in the firewall to disable QUIC from bypasding the proxy.   You can condider adding it as an additional service to allow it as long as the standard proxy is used.   If QUIC is blocked, normal TCP 443 is used.

    Sophos has made no statement about their ability to evaluate QUIC traffic, so I have chosen to keeo it blocked.

  • To elaborate on QUIC:  my testing says that Chrome behaves as follows:

    1) attempt UDP 443 on standard proxy (UTM will return an error by default, causing the search to continue.)

    2) attemot UDP 443 without proxy (UTM will typically allow because of a catch-all "allow all outgoing" rule.)

    3) attempt TCP 443 using standard proxy.  (UTM will typically respond somehow, ending the search sequence)

    4) attempt TCP 443 without proxy.

    If standard mode is not used, UDP 443 is not detected by the proxy.

    So you need to block UDP 443 at the firewall, in all configurations, to prevent Chrome from byoasssing your proxy, regardless of which proxy mode is used.  

    Adding UDP 443 to allowed services will allow QUIC to flow through the standard proxy, if you consider this desirsble and you are using standard mide.

  • Since Chrome, unlike some other browsers, can be managed wonderfully via GPO, it is at least possible to deactivate QUIC. In a Windows domain this is an advantage not to be underestimated.

    Maybe Sophos will someday position itself on QUIC.

    Best

    Alex

    -