Another old way I'd block facebook, was to add its domain into the local dns and point it to the IP of my client's own website. When someone tries to go to facebook they see their own company's website instead
With this, you can also enable transparent DNS cache, so that if they try using a public dns, it will be intercepted by the local DNS after entering the Zentyal Gateway.
However, I like the method I mentioned earlier better and there's no reason you couldn't implement both methods at the same time to be even more confusing.
No matter what you do, there's always ways around it, but you can at least make it as inconvenient at possible. These methods stop most users from getting to facebook.
Christian, I'm not too concerned about the scenarios you mentioned regarding the "blocked ip ranges" method. For one, I don't expect to get too many complaints from users about sites they cannot get to (due to that filter rule). Also, I'm not totally blocking those ranges, I'm only blocking https to those ranges. So if there is an http website within those ranges that is not Facebook, they could still see it. In the very rare instance that the user may need to fill out a https form on websites in those ranges (which would probably be extremely rare for a work related task), I could easily modify the ranges in my facebook network object.
If facebook buys new IP ranges, I will notice activity in the logs and block those too. Hopefully by that time, users will already be trained that facebook doesn't work and give up on trying.... if not I'll block the new ranges...