grant_girdwood

Indeed it is, yet surprising how many folk don’t do this

When I last looked at this a couple of years ago Psiphon uses SSH to connect but will obfuscate this over ports you wouldn't expect, typically it was over DNS - blocking port 53 on the firewall and only allowing it out from your trusted servers typically done the trick - appreciate this may not be the case now but could be worth a punt. Good luck!

If they have downloaded the PAC file on-network, it should cache the file locally, but this can depend on the settings on the local machine. You'll be able to craft your PAC file with the desired behaviour if your proxy is not reachable from their network location.

You could set up a squid proxy and on that proxy box have the hosts file to point to the restricted youtube. Create 2 x pac files, one that points youtube traffic to the "restricted proxy" and the other to your existing proxy or however you access YouTube just now, then deploy the pac by group policy.... Of course you could flip the above about

Hi Clare, Is it fine on other browsers? Give the team a call and we'll be able help you investigate further. Cheers, Grant p.s. down at BETT this week on stand F330 if you're around and want a chat.

Wireshark could be your friend, or you should be able to setup a rule in Websense to allow the User-Agent string that Office products use.

No worries - feel free to thank the posts

Ah yes, caching of old proxy files can be a pain - especially in Windows. Have a look over at http://www.findproxyforurl.com - really useful resource for WPAD/PAC file information. Have a good weekend.

They should do, are they within the 10.130.113.x range and is that how you're accessing them (e.g. http://10.130.113.50)?

Also just looking at your original file I can see where you went wrong, WPAD/PAC files work in a top down manner and as soon as it matches a rule it won't look any further, so as you had specified the network first it meant that any rquest from the internal network would always hit the proxy regardless of what was being requested.

Not a problem - here you go; function FindProxyForURL(url, host) { // Bypass proxy for local servers. if(isPlainHostName(host) || dnsDomainIs(host, ".internal.local") || isInNet(dnsResolve(host), "10.130.113.0", "255.255.255.0")) { return "DIRECT"; } if (isInNet(myIpAddress(), "10.130.113.0", "255.255.255.0")) return "PROXY sslfilter.proxy.swgfl.org.uk:8080"; else return "DIRECT"; } http://i.imgur.com/s888z0F.png At line 5 if you change internal.local to match the internal domain name e.g. bloxx.local whatever the set up, just means if someone attempts to get access to something via DNS and it's internal it won't hit the proxy. I've also set it up so that if there is a local DNS request (e.g. localhost) it won't hit the proxy

P.s. let me know what you want from a PAC file and I'll throw one together for you. e.g. if you're in network X use proxy, or not, if you're making a request to a local domain (e.g. something.internal) not to use the proxy etc.

It will just assume you have an IP that isn't listed in your PAC rules, so if it doesn't match else where it will hit your default/capture all rule at the end of your PAC file which bty the sounds of it is is direct.

MathsNet: Java Technical Help

Would be worthwhile running a Wireshark and inspecting it to see if anything is being dropped or what URL it is failing on... p.s. have you tried contacting mathsnet for support?

IIRC you should only have the GP option for IE10, anything above IE10 will get those settings. Give our support team a call and we'll be able to check out if the traffic is reaching the Bloxx appliance from the client which should hopefully help

p.s. here is the download link to the tool for windows - https://github.com/pacparser/pacparser/releases/tag/1.2.7

Ok, so there is a syntax error, you've missed out a closing bracket at the end of line 3 Once correcting that it looks good to go. See below; 1) requesting google.com with no client IP specified, result = DIRECT 2) requesting google.com with a client IP within range specified, result = PROXY 3) requesting google.com with a client IP outwith range specified, result = DIRECT

If you download the windows version and extract it to somewhere on your C:\ drive e.g. C:\wpad - also throw a copy of your PAC file in that folder...will make it easier in the command prompt... Open up your CMD prompt cd in to the directory you created interrogate the file using pactester, just run pactester and it'll tell you how to use it e.g. pactester -p proxy.pac -u http://google.com -c 192.168.10.1 where -p is the file -u is the URL and -c is the client IP address It will list the output (proxy or direct) and highlight any syntax errors.. A handy tool!

seems ok, use pactester to test it out. https://github.com/manugarg/pactester so you know the recent windows versions are broken - there are older version downloads there.

5223 is the port that iMessage relies on - https://support.apple.com/en-us/HT202078 Do you have a separate part of the network BYOD connects to? I'd suggest segregating your network so that there is a BYOD specific one where you can block 5223. For owned devices where you need your MDM to connect have them connect to a different part of the network where 5223 is allowed?

You can restrict logging in with consumer accounts by modifying the header in the request - https://support.google.com/a/answer/1668854?hl=en Which would result in the below... http://i.imgur.com/whzUZXR.png It does appear to be a backwards step geared to getting more schools to sign up to Google Apps for Edu..

If you deny translate.googleusercontent.com - this will block the page translations but allow them to use the text translations.

Hey @jaminben They've moved it over to their privacy page, seems to be 13+ - https://twitter.com/privacy?lang=en

You'll need a product that can perform full SSL decryption so that it can see the full path that is requested. Without SSL decryption the most they will see is that sites.google.com has been requested, the content and importantly the path will be encrypted so the Meraki appliance will be unable to see this content. Hope this makes sense. Cheers, Grant