SSL/TLS : ERR_CONNECTION_RESET Issue

Hi,

which firewall rule is blocking the traffic? There is also  possibility that the tecmint site is using other URLs which you have blocked.

Please post the bottom half of the firewall rule.

A suggestion, you could simply your rules by using LAN as the source zone.

Ian

Hi rfcat_vk ,

Thank you for your reply. The issue is related to my SSL/TLS policy ID 6 (MyExclusions). Please note that the firewall rules where these sites are whitelisted do not have web and app filtering enabled.

The URLs belong to Information Technology and online shopping categories, which are not blocked by my web filtering. I’m using a single web filtering policy for all my LAN to WAN traffic, as detailed below:

Web Policy (HomeWeb-Filter)

List of web categories: Advertisements, Anonymizers, Auctions & Classified Ads, Command & Control, Criminal Activity, Gambling, Hacking,

Marijuana, Nudity, Peer-to-peer & torrents, Personals & Dating, Phishing & Fraud, Pro-Suicide & Self-Harm, Sex Education, Sexually Explicit,

Spam URLs, Spyware & Malware

SSL/TLS Policy:

Firewall Rules (MyExclusionList)

I’ll keep your suggestion in mind. The reason I set up the LAN zoning was to easily identify each network within my home.

I see, that’s why you didn’t encounter the issue I faced with DPI, where some sites throw a "connection reset" error. Did you try replicating this behavior in your own environment?

Also, I believe Sophos uses web filtering to block sites, maintaining a dedicated and regularly updated set of categories. My understanding of DPI (Deep Packet Inspection) is that it scans and decrypts traffic, blocking malicious payloads or malware when detected, but it is less focused on site blocking. Blocking becomes more comprehensive when the two approaches are combined. Both DPI and Web Proxy have their own advantages and disadvantages, depending on the user’s implementation and requirements. In my case, I prefer to use DPI.

Now I have the network to myself, I will setup a rule and try.

Ian

I tested without any issues.

I think I see your problem. You need to enable web using allow all.

Ian

It looks like you’re right. When I allowed all web filter rules, it worked. I’ll try to figure out what’s stopping it when the web filter is enabled. You may also be correct that they’re using a different link upon loading, or perhaps a 301 redirect is causing the connection reset (Server did not respond to client hello) in the Sophos SSL/TLS filter logs.

This is funny—it works for a while but then reverts to the same issue. I tested it on a separate network with IPS, Web, and App filters enabled, but with SSL/TLS scanning disabled, and it works. The issue only occurs when SSL/TLS (DPI) is enabled. I’ll run some additional tests to investigate further.

I have SSL/TLS enabled all the time. I have a number of exceptions but not tecmint.

Ian

Just to update this thread: it seems the issue was related to the MTU. Referencing this topic—  SSL Inspection Microsoft Stream: Server did not respond to client hello  —after adjusting the MTU, the issue was resolved, even with SSL/TLS enabled.

Bad news—and quite ironic! The issue still persists, and changing the MTU didn't help. It worked yesterday, but today the same issue is occurring. Can someone from the Sophos team take a look at this?

Ian, neither Web Proxy or DPI mode looks at UDP packets (QUIC), which is why there is a checkbox to block all QUIC if you want to force it to HTTP/HTTPS.

DPI vs Web Proxy (legacy)
- 99% of the feature set is the same
- both support transparent mode
- only web proxy supports direct proxy mode
- both detect malware (if enabled in firewall rule)
- both block websites, etc
- both can decrypt https although the configuration is different
- proxy has specific features that DPI does not such as SafeSearch. For some customers that makes proxy a requirement.
- DPI has specific features that proxy does not
- Application Control is configured and implemented separately. Both support App control equally.

Back when DPI was introduced (v18) it was new and had some problems with specific websites. It got a reputation for not being as good as the legacy proxy. However I think that reputation is undeserved in the last few years. DPI mode is more sensitive to network configuration, topology, MTU, etc.

I encourage you to use DPI mode. That being said, switching to proxy mode may be an interesting test to help narrow down the problem.

---

Destination networks that are FQDN hosts are poor performance. This is absolutely true in TLS rules but I believe in firewall rules as well. This is because it needs to look up the FQDN to see what IPs are associated and it needs to do that every connection because the IPs can change any time.

For TLS rules, look at support.sophos.com/.../KBA-000008111
For Firewall rules, if you purpose is to create a whitelist that does not apply policy, either do it in the web policy, or use a web exception.
You may want to look at support.sophos.com/.../KBA-000004901

To think about it a different way, think of the layers of networking. The best place to make decisions about decryption is the layer where we see SNI, not IP addresses. The best place to make decisions about web policy is where we see HTTP/S requests, not IP addresses.

This is not likely related to your problem, I just want to set you on the right path.

---

The problem might be in kyber support, try disabling in the browser. This increased the TLS handshake to that it is larger than a single packet, which DPI mode has problems with.
support.sophos.com/.../KBA-000009276

DPI vs Web Proxy (legacy)
- 99% of the feature set is the same
- both support transparent mode
- only web proxy supports direct proxy mode
- both detect malware (if enabled in firewall rule)
- both block websites, etc
- both can decrypt https although the configuration is different
- proxy has specific features that DPI does not such as SafeSearch. For some customers that makes proxy a requirement.
- DPI has specific features that proxy does not
- Application Control is configured and implemented separately. Both support App control equally.

Back when DPI was introduced (v18) it was new and had some problems with specific websites. It got a reputation for not being as good as the legacy proxy. However I think that reputation is undeserved in the last few years. DPI mode is more sensitive to network configuration, topology, MTU, etc.

I encourage you to use DPI mode. That being said, switching to proxy mode may be an interesting test to help narrow down the problem.

---

Destination networks that are FQDN hosts are poor performance. This is absolutely true in TLS rules but I believe in firewall rules as well. This is because it needs to look up the FQDN to see what IPs are associated and it needs to do that every connection because the IPs can change any time.

For TLS rules, look at support.sophos.com/.../KBA-000008111
For Firewall rules, if you purpose is to create a whitelist that does not apply policy, either do it in the web policy, or use a web exception.
You may want to look at support.sophos.com/.../KBA-000004901

To think about it a different way, think of the layers of networking. The best place to make decisions about decryption is the layer where we see SNI, not IP addresses. The best place to make decisions about web policy is where we see HTTP/S requests, not IP addresses.

This is not likely related to your problem, I just want to set you on the right path.

---

The problem might be in kyber support, try disabling in the browser. This increased the TLS handshake to that it is larger than a single packet, which DPI mode has problems with.
support.sophos.com/.../KBA-000009276