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.

Hi there, Just having a quick glance at some of the code, do you have any temporary bans (Services > Authentication > Temporary Bans) currently in place? If you do, can you try removing these, restarting authentication and if that works re-create them. This may be the same for if you have ever "overloaded" AD users by creating a user with the same name in Local Users, to assign a user to a different group than AD is telling us. Let me know how you get on, Rob.

If it doesn't support NTLM Auth you might want to try putting the domains it requires into Guardian > Authentication > Settings "Do not require auth for" box - not sure off the top of my head which ones it may be, but dropbox.com would be a good start. Hope this helps, Rob.

When you connect to a server you open up a local high numbered port to connect to the remote port 443 on the server, like.. mypc:31225 -> mailserver:443 So that's not a problem. Is it actually a 404 you get, as that would indicate that the webserver on the mailserver is returning content (404 is a message that the server itself sends, not that the browser generates to say it can't find something). First place that I would check is the mailserver - if you've previously had two NICs and now are using one, make sure that you have the correct default gateway set. The internal NIC needs to have its default gateway set to the SmoothWall so that the packets can get back from the mailserver, to the SmoothWall, then back on to the remote client. Also you might want to set up source mapping so that when the mailserver goes outbound it uses the same alias IP - otherwise you get a situation where mail comes in on one IP but the server sends out on another; some external spam systems will flag this as dubious and you might get blocked. Hope this helps, Rob.

If you're not doing transparent filtering (i.e. you set the proxy in everyone's browsers) try turning off transparent in Guardian > Proxy > Web proxy to see if it improves your non-domain PCs. mb2k01 - with regards to your internal sites, have you tried excluding them from going through the proxy via the GPO/browser settings? I believe there was a recent update to facilitate authenticating to another NTLM upstream web server through the proxy when using NTLM, but generally this is unwanted as most people don't want their workstations to automatically auth with any random internet server.

dgordon - everything looks fine with your usernames, basically top two boxes are user and @domain and next two Netbios domain name then user. The system assumes that your Netbios domain name (i.e. the domain name you usually see in the windows logon box on a workstation) is the same as your DNS domain name up to the first dot (e.g. netbios domain name = school, DNS domain name = school.grid.sch.uk). If this isn't the case then you might need to specify it separately in the authentication settings. However if this isn't right then using NTLM Auth will fail straight away and the proxy won't be able to join the domain. If user@domain is missing generally you see people being authenticated, but no groups found which causes them to go to Default Users. You should be able to see this usually in the authentication logs. Do you have Default Users turned on, as if you don't it may be then falling back to Unauthenticated IPs. Having said that, Use SAMAccountName should avoid that anyway by not using the @domain part of the username. I see Linkazoid has a ticket open with support on a different issue, you might want to hijack it with this one too and see what they reckon. Same for dgordon, if you can't get anywhere with this feel free to call in.

Actually just seen you say that Firefox automatically and invisibly logs you in without asking for username and password. In which case is there anything that might make IE think that the SmoothWall isn't a local system, hence not automatically sending login details to it? Like it being on a non-local subnet or by non-standard local intranet zone settings?

Good stuff. Assuming you're using NTLM Authentication - is this a domain workstation on the same domain as the SmoothWall? Are you logged-in with a domain user account? Ta, Rob.

Hey Dom, Two quick things that might help - when using Internet Explorer how are you setting your proxy details? If using manual configuration ensure that you do not proxy for the SmoothWall itself - might need to do this by IP, hostname and FQDN depending on how IE feels today Alternatively if you use the auto configuration script at http://smoothwall.address/proxy.pac this should set it up for you. Also, if you're not intending on doing inline transparent filtering, make sure that transparent isn't ticked on Guardian > Proxy > Web Proxy (towards the top) then save and restart. Hope this helps, if not please let me know. Thanks, Rob.

So Networking > Interfaces > DNS points at Windows DNS server. Windows DNS server is set up to forward DNS requests to the SmoothWall, which uses the SmoothWall's DNS Proxy (Services > DNS > DNS Proxy, make sure enabled for your internal interface). SW DNS Proxy forwards on DNS requests to your ISP's DNS server as defined in the Networking > Connectivity page. All internal clients use SW as default gateway. Subnets defined on the SmoothWall so that it can route traffic to internal VLANs/other networks as required. Networking > Outgoing > Sources on the SW should be set up to reject outgoing traffic from all machines other than those that need direct internet access (e.g servers). If you need to use an upstream proxy to get to the web, make sure is set in System > Maintenance > Registration options and Guardian > Web Proxy (Prior to FP3) / Guardian > Upstream Proxies (FP3) Does all that look like what you've got? How's it failing at the moment?

Yep that's right, you should only ever have one default gateway. Also make sure that your internal DNS server (as set on Networking > Interfaces) is an Active Directory DC/DNS server if you're linked to AD. Apologies for the delay getting back to you on this, been on the road all day and only just got back in.