This might be of use for me in the future when I’ve managed to lose an existing configuration or setup – or might be of use for anyone reading this who needs to do something similar to one of my setups.
I have a customer who uses Squid in their network. The Squid proxy is used to do content filtering to prevent access to undesired content on the internet. However – to do this Squid passes all the requests on to a cloud filtering company.
The side effect of this is, even though the cloud filtering company servers are based in the UK, the BBC have tagged the egress IP as being something that they don’t allow on iPlayer! Here is the response from BBC support…
I understand you’re unable to access iPlayer as you are not recognised as being within the UK.
Your IP is showing as being registered to CLOUD FILTER COMPANY DATACENTER NAME REDACTED (third party IP databases concur). It’s also listed as proxy type: hosting, proxy description: dns. While the proxy type itself indicates that this IP isn’t recognised as a broadband connection, it’s the description of it being a DNS that is actually causing the block here.
This all seems like going the direction of getting the BBC or their “data provider” to re-categorise an IP that the customer doesn’t even own will be far too difficult.
The easiest solution was to work out the configuration required for only allowing the iPlayer content to go direct and bypass the upstream cloud filtering company.
The following lines in the correct positions within the Squid config did the trick. In this case I’ve just made all of bbc go direct as I was too lazy to identify just the iPlayer domains.
acl bbcuksites dstdomain .bbc.co.uk .bbci.co.uk
tcp_outgoing_address 10.0.0.253 bbcuksites
tcp_outgoing_address 10.0.0.254 !bbcuksites
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1 all
ssl_bump splice all
In this instance they were using squid as an https_port and http_port “intercept”. You may not need the SSL Bump stuff if you are using Squid as an explicit proxy as the CONNECT request seen by Squid is likely to be the hostnames already instead of just an intercepted IP.
If using intercept… Squid needs to have ssl-bump enabled which also means you need to be running Squid 3.5 or higher. SSL peeking is required so you can tell the https sites being accessed. A couple of components on iPlayer (even though the main page is non-https) are over https:
Looking up CONNECT request from 192.168.35.4 with url component.iplayer.api.bbc.co.uk:443
Without ssl peeking Squid would only see “184.108.40.206:443” and wouldn’t know to send that traffic direct.
In the example config lines above I’m using source based routing at the router. Traffic from 10.0.0.254 goes via the cloud provider and traffic from 10.0.0.253 goes direct.
You could easily change this to just parent proxies, tcp_outgoing_mark or any other similar routing rule ability.