I think this depends on where the request is blocked. I would expect the following behaviour:
- If you block accesses to the URL www.download.com all attempts to download something will be blocked by MWG when the request comes to MWG. MWG does not need to talk to the server to find out that a request should be blocked. So the traffic between MWG <-> Server should be 0, however some bytes are still transferred between Client <-> MWG.
- If the download attempt has been blocked by a Media Type Filter or AV Engine then MWG has to grab the content before it is able to block. In case MWG decides to download a file (because it was not blocked during response) traffic will occur between MWG <-> Server. After MWG downloaded a file it may find out that it should be blocked, but traffic already was made.
I believe to correctly find out what happens in your specific case it would be helpful to see how such a blocked request looks like in the log file and which fields are logged. Maybe some of the guys more familiar with Web Reporter can help, but this is what I would check from an MWG perspective.
If you divide the number of bytes by the number of hits, that's about 4~5k per hit. That's about the size that a block page takes.
A torrent client continuously attempts to connect to the tracker. If it cannot, it just keeps trying. Each attempt generates a block page returned to the client. And each of those block pages adds to the total bytes.
Although no traffic is happening on the internet side of the gateway, there are bytes getting sent from the proxy back to the client and that's what is being counted.
Seem logical when you put it like that!!
Ok - going to see if we can block it at the Aruba Controller then and stop it before it even reaches the proxy.