The request was aborted: Could not create SSL/TLS secure channel.

Running v18 EAP1:

 

Have simple firewall rule, which allows traffic to the Internet, there are NO security features setup on XG in the rule, only a NAT:

 

I have a Playstation on the LAN and also a server that sends out to PushOver, now the Playstation cannot connect to the playstation network, and Pushover is being stopped, I get this from ex. Pushover:

"The request was aborted: Could not create SSL/TLS secure channel."

I have disabled SSL inspection also on XG.

 

Some services work, but others don't on the network.

 

I found out, that if I go and enable this:

 

 

Everything works again!

What could be wrong here?

With 17.5.8 I had the same rule, with no security enabled, no issues here.

The sometimes I can disable the proxy again, and it keeps working, just as if it hold the connection.

Would make sense if the SSL inspection on/off was broken, and it was still on, but I cannot understand why SSL/TLS is broken, with it all disabled :-)

Parents Reply Children
  • LuCar Toni said:

    Proxy (the HTTPS decryption in Firewall policy) enable the "V17.5 Proxy" and you will bypass the TLS encryption for HTTPs, because the Proxy will accept those packets.

    Thanks for the reply  I have not seen this post before :-)

    But, my issue was this:

    - Have SSL inspection disabled

    - have Web proxy (17.5) disable and None in Web policy

    - have Firewall rule that allows ANY service to WAN.

    TLS/SSL was broken for LAN, no matter if I enable or disable SSL inspection, only when I made the exception, things started to roll perfectly :-)

    Should this not work, with exception, if SSL inspect is disabled, and all proxy features are disabled?

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v20 Technician

  • I guess this is a bug and someone should investigate. If any service and not web filtering  is applied, neither the proxy mode 17.5 or tls/ssl inspection should intrude.

    If this is not the case, how can we prevent that proxy or dpi engine intrude?

  • Sounds odd to me, did not see this before.

    I would say, maybe there was another policy, picking up this traffic?

    Because if you create a Web proxy exception, it will be used for ether DPI Engine or Web Proxy (old). 

     

    So most likely, any rule picked up this traffic and the exception solved this or there was another rule involved. 

    Can you actually reproduce this issue right now? 

    __________________________________________________________________________________________________________________