DPI Application Control Blocking Rules cause huge delays for clients by failing to RST connections
Application Control Blocking Rules causes huge delays for clients, because instead of rejecting blocked traffic with a RST packet, they instead drop / black-hole the traffic. This causes clients to wait the full connection timeout for a connection that will never come. This causes one or multiple hang-ups of 30s for clients.
For example, consider a rule blocking ads for a hypothetical web page load. The original, unblocked page load was as follows:
- Request page: 2 seconds
- Request ad: 2 seconds
- Request ad: 2 seconds
- Request page content: 2 second
Total Page Load time: 8 seconds
Now if you enable an Omada Application Control Blocking Rule for ads, in it's current form, where blocked traffic is dropped / black-holed:
- Request page: 2 seconds
- Request ad: 30 second timeout for dropped traffic
- Request ad: 30 second timeout for dropped traffic
- Request page content: 2 second
Total Page Load time: 64 seconds
Omada Application Control has made the client's experience 8x times slower!!
If Application Control worked correctly, it would reject blocked TCP connection attempts by returning a RST packet to the client. This would cause the client to give immediately and move on, e.g. for or web page load:
- Request page: 2 seconds
- Request ad: 0 seconds (blocked with RST)
- Request ad: 0 seconds (blocked with RST)
- Request page content: 2 second
Total Page Load time: 4 seconds
If Application Control worked correctly it would be a benefit to the client and site operator by speeding up performance (8 secs -> 4 secs). Instead, in it's current form it makes everything slow for the clients / users (8 secs -> 64 secs)!
In my opinion the correct behavior for Application Control for internal clients is to return a RST packet to the client.
If this is not always appropriate for all rules, my alternative suggestion is to add a "Block with RST" option to Block Rules, e.g. see mock-up below
Thanks for the reply @Clive_A! The web page was an simple constructed example. The actual behaviours are more complex, but the impact is still negative. Even with parallel requests the page load may not complete for a long time. So while you can see the content, the 'spinner' will keep spinning, potentially delaying other post-page loaded behaviours. If client does do retries at you describe, the connection timeouts will keep stacking. More generally this applies to any TCP client connection that matches a blocking rule. Retries are actually more likely without a RST, since the client doesn't know the reason the connection attempt didn't work, versus telling it connections are rejected.
I have disabled the DPI blocking for now. Too many complaints of "slow Internet" traced to this.
Let me give you and even simpler web example for the ad block rule situation. Let's say you go a Google search for "new car". The first results will no doubt be sponsored links, which relay through:
https://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcS....
This will be blocked, as it should. But with other DPI products I've configured over the years, it will get blocked instantly because a RST is returned to the client by the blocking firewall / router, so the user will know immediately, and is in no doubt. With Omada, the connection attempt is simply dropped / black-holed and the human is left watching the browser spin wondering what is going on, is the page just slow? How long should I wait?
Effects can be a simple an an application installer trying to log install statistics. Sure it only adds up to 30 seconds to that application install, but it's an unnecessary delay, easily avoided by actively blocking blocked connections with a RST.
Returning RST for a TCP connection attempt is simply the correct TCP protocol for rejecting a connection. Black-holing traffic is bad manners! 😅 I understand that you might not want to do that externally blocked traffic, least a reflected RST attack is possible, but interally I've always configured DPI systems to RST connection attempts, because of the drama black-holing traffic on internal networks causes. A RST reply is stateless, it doesn't create any connection tracking or other overhead for the router DPI, other than sending a packet.
I appreciate there are situations where dropping traffic is appropriate. Which is why I suggest this is a per-blocking-rule options.
In my experience other product supports both "Block" (drop) and "Reject" (RST) options; everything from pfsense to AWS firewalls (see below).
I hope you'll investigate the behaviour of competing products, and also test impact on clients and hopefully see the value of this 🙏
