Mon Jan 04, 2021 6:48 pm
So what you are actually saying is that the "real internet" traffic heavily inreases the use of the bandwidth if no limit is imposed on it, and the only reason I can imagine is that the content available via Internet Exchange is much less attractive than the one available via Real Internet.
OK - from what you say it seems you already have two bandwidth limitation classes per user, and you classify the traffic based on the "remote IP" (seen from user perspective), where some prefixes (subnets) identify the Internet Exchange class, and the rest is classified as Real Internet. So to me, the whole task is to find out whether the IP addresses of the VPN servers are static or dynamic, and if they are dynamic, to find out how do the VPN clients learn them. And then make traffic to/from those servers be classified as internet one although the addresses are actually from the Internet Exchange address space. The actual bandwidth through the VPN will be slightly less than the one of direct access to Real Internet due to the VPN overhead, but I don't think it should bother you.
From legal point of view it may be a bit complicated, it depends on how your end user contracts are written (whether they expressly prohibit use of technical means to overcome the bandwidth regulation).
What you are not able to do is to selectively throttle only those VPN packets which carry the Real Internet payload, so if the VPN client software is so stupid that it sends everything through the tunnel, by the above you'd limit also the Internet Exchange traffic for the VPN users.
But more important, as soon as providers of attractive contents build local caches for it within the Internet Exchange address space, you'll be back where you are now, as the actual issue is not "Real internet" vs "Internet Exchange" but attractive contents vs. inattractive one. And blocking or bandwidth-limiting just part of Google or Facebook services selectively while leaving other services of the same providers unrestricted is a mission impossible.