rob_f

Chrome browser on iOS does not refer to the device's local certificate store for certificate validation, so you will have problems with Chrome. I don't believe Google currently offer a way to deploy certs to Chrome on iOS - it may be possible if these are Google Apps users through device management, but last time I checked it only worked for Chromebooks.

No need to do WPAD as you can just do transparent filtering so you won't have the hassle of ensuring that the clients are configured properly. I'd try to explain the physical/VLAN setup choices for the new SSID, but I think you guys covered it. Plus the last time I tried to do that was to @Dos_Box last week about the setup for Smoothwall and Edugeek at BETT and since then we're no longer on speaking terms ;-)

Hi Stuart, Which Smoothwall product is it that you're using? If it's Network Guardian or SWG then you'll need to speak to the support team to get the bridging module ("SmoothZone"). If it's Advanced Firewall, School Guardian or UTM then you'll need to put a rule in Networking > Zone Bridging to allow those two networks to communicate. On NG/SWG without the bridging module nothing is allowed to pass between separate network zones, only web traffic being filtered. Additionally it looks like PC-A needs to have the Smoothwall as its default gateway, not the firewall. If you could add the network ranges and subnet masks to the interfaces on the diagram this will highlight for us what you've got set up and what might need to change. Hope this makes sense! Rob.

When you say OpenVPN, is this a VPN that the SIMS server makes back to Capita?

I think it might be something like media-imdb.com... if your web filter can't tell you then try either wireshark/firebug/fiddler on the client PC or inspect the HTML.

Processing domain name sets and URL sets suggests that the only way you can block HTTPS sites by domain is to provide it in a Domain Name and URL Set without protocol and a slash at the end, e.g. rather than "https://www.google.co.uk/" just put "google.co.uk". Which will of course then block plain HTTP google... Essentially what's saying is that as soon as you stick a slash on the end or protocol in front, it is then a URL and can only be matched against HTTP. The only way a proxy/filter can block HTTPS by URL is using HTTPS Inspection/SSL Decryption. You can try blocking "encrypted.google.com" but I don't know if that covers 100% of the secure search angles.

If you PM me your school name and LA I'll check straight away for you why you can't get the unfiltered access you should have. Thanks!

Hi all, Sorry to hear you're having problems with speed... I haven't heard anything about this myself but if you make sure it's logged through your LA the guys can investigate. As for things like ebay, dilbert, xkcd and so on - the filtering rules are slightly different but if you see a blockpage this should be fairly obvious - i.e. if it says blocked because of Online Auctions, Jokes and Humour etc. Again, please report to your LA and if it needs to be allowed for your school follow the usual unblock channels (of course you'll be able to do this for yourself shortly with the swurl system). There was a considerable testing phase with a wide range of schools, and testing is only as good as the feedback you get - so apologies if we've missed a few things but a little bit of teething is inevitable with any change on a scale like this; be assured we're working to resolve things as quickly as possible, but not to sound like too much of a broken record but make sure your LA are aware of any troubles, questions or queries you might have. The login "elevation" facility is something we are aware of and will restore as quickly as possible - until then there is always the ability to use different ports for different policies - so if you need your staff to get filtered differently to students you can request this through your LA then push a different proxy port to groups of users through AD or whatever. Thanks!

If it's listed as "Exception" then file download rules aren't being applied to that domain. The ultimate test is to put the TMG server's address in Guardian > Web Proxy "Exception IP Addresses" and set TMG to use port 801 on the Smoothwall... this is the most extreme form of whitelist/bypass and should help you eliminate your policy configuration.

I'm not aware of any GPO/proxy settings problems with 7 & IE9, but you never know... is there maybe a "group policy preferences" style setting in there that's overruling a "group policy normal" setting? Maybe try a RSOP? Little bit OT, but do you know you can write one PAC that delivers different proxy settings based on the machine's subnet? This sort of thing... if (isInNet(myIpAddress(), "192.168.1.0", "255.255.255.0")) return "PROXY 192.168.1.1:8080"; if (isInNet(myIpAddress(), "192.168.2.0", "255.255.255.0")) return "PROXY 192.168.2.1:8080";

Is the Exchange server currently sending directly out, or is its return path through Zimbra? Just trying to work out firewall/routing wise if everything is OK with it... i.e. check the gateway, any outgoing firewall policy, maybe you have a source mapping set up for Zimbra that Exchange doesn't have, and the Lancs relay refuses to talk to anything but the external IP mapped to Zimbra? Few thoughts after your plea on twitter ;-)

Excellent - the thing is that in transparent mode the Smoothie has to be a bit more "aggressive" with how it checks peoples credentials, which although shouldn't cause issues like this (we'll still look into it) can change NTLM's behaviour a little. Auto proxy config with laptops should be fine, you might want to set "wpad.yourdomain.local" in your local DNS to be the smoothie's IP as some browsers will use this to find the proxy... this may also rely on DHCP passing "yourdomain.local" as a DNS search suffix. New filtering engine due out late this summer should allow you to do transparency per-interface, as well as generally tweaking the whole NTLM process, so look forward to that! (I am :-) )

Don't suppose you've got transparent filtering enabled have you (Guardian > Proxy > Web Proxy towards the top). If you're filtering explicitly (i.e. setting browser proxy settings) try turning transparent off, it may help you out as NTLM is performed a little bit differently.

Yes, we used to see that sometimes with SmoothWall Guardian but everything should be fine as far as filtering is concerned if that's what you're using. It's almost always the CSS getting blocked somewhere. Remember if you're using SmoothWall and trying to troubleshoot blocks like this, CSS is hidden by the Web Filter Log Viewer's exclude mask so you might need to turn that off.

Cheers, I've alerted support so if no dice from this please PM me your details and they'll get in touch. Ta, Rob.