nile_c

I would suggest looking into the logs on the Smoothwall and filtering them via the IP address of the client machine at the time. This should indicate whether you're getting the expected authentication, and what filtering polices were in effect.

Another option is that the Superhub has stolen the IP of the smoothwall system. If you try browsing to the IP without specifying a port (e.g http://192.168.0.1/) you would see a Virgin branded settings page if the above is true.

I had confirmation from Youtube (overnight) that this was a temporary issue and is now resolved. Haven't tested it myself, but it appears you folks have!

I've had reports from elsewhere, but we're still trying to confirm and understand the cause.

If nearpod would like to get in touch, do let us know. Myself @OB1 @ibpalle or @tom_newton will be able to organise some sort of diagnosis tag-team

First port of call would be to check out 'Logs and reports » Logs » Web filter' on the Smoothwall web interface to locate any blocked requests. IIRC it would be a ggpht.com or an googleusercontent.com domain.

It's relatively straightforward to set up HTTPS inspection. However, you'll need to make considerations such as how the CA certificate will be distributed, what you'll do with byod devices, whether you'll be emailing users first, etc. You can view a short video here: 3 - Smoothwall - HTTPS Filtering - YouTube Also check out our knowledgebase accessed via the support portal. As @OB1 and @Oaktech have mentioned, you can block the sites.google.com domain in the meantime.

I can't speak for the official lightspeed advice, but I know of at least one Smoothie customer who is doing this successfully! Let me know if you run into any snags while testing.

It sounds to me like Google is transferring signed-in users onto an HTTPS connection. What's the situation with the LA filter and secure sites? If the issue is HTTPS, you could look into the NoSSLsearch option provided by Google. This causes Google search to revert to plain ol' HTTP connections. Obviously it's no help for the rest of the web :-)

For a Smoothwall user, yes it would. Within 'Web Proxy > Authentication > Exception' you could add the category 'SSL /CRL' which includes the relevant CRL and OCSP servers. ... in fact, that's part of the new (March '13) example policies for a new installation.

If it isn't obviously your web filter, try your firewall. In particular, the flash object might be using RTMP (port 1935) as a streaming transport.

Good morning folks! We're hiring again at Smoothwall. The role is as an Internet Analyst within the team that develops the Guardian blocklists. Full details are at - Internet Analyst. Please get in touch with me or @tom_newton if you need to know anything else.

Hi Kenny, sounds to me as through this is an issue with Ranged GET. The iOS Youtube app uses ranged gets requests, which your smoothie won't allow by default. You'll need to add a rule for the relevant location/group. Have a gander at this: http://www.edugeek.net/forums/smoothwall-direct-support/95393-youtube-broken-ios.html Cheers

That all sounds good. It is now mounted and available at /raid1 As you say, modern file managers will generally have handy links for Home and Root, etc. If you plug in a removable storage device, or insert a CD/DVD these also show up and you can mount/unmount them as a regular user. Dolphin isn't likely to show your raid array here, because it's already configured in your fstab and mounted. However you can navigate to /raid1 and use it as you would any other directory. The permissions might need to be made more permissive EDIT: What CAWJAmes said! I got distracted before I hit 'post' on mine

Hi tickmike, Good luck with your smoothie! As for the NAS... df is showing it's not currently mounted, and the 'mount: /dev/md0: can't read superblock' is telling us that it isn't formatted. So you'll need to go ahead and do that. As always with partitions and formatting, here be dragons. Now you have a partition on each disk (/dev/sdb1 and /dev/sdc1) which are "real" block devices. mdraid has built your RAID1 atop both of these, and now you've got the "virtual" block device /dev/md0. From here on we can forget about the real disks and refer to '/dev/md0'. The kernel will handle the RAID stuff behind the curtain. If we play with sdb or sdc the data gods will harm us. In the simplest case you can format with: mkfs -t xfs /dev/md0 Did you really want XFS? If not you'll need to change the -t parameter to reflect that.

It's been a very long time since I've used anything Mandrake/Mandriva related, so I don't know much about diskdrake. Can you run, df -h at the terminal? If you can see /raid1 there, then we'll know the array was definitely formatted and is mounted. If all's well, then the next step will be to edit /etc/fstab to ensure the volume (md0) is mounted at boot. (Or perhaps you can do it in diskdrake)

Hi glennda, IIRC Flickr's safesearch (equivalent) will restrict access to that tagged content and we enforce their safe search. But rather than rely on my memory, I'll get someone to review it again today

As I recall, you can configure X to load an application immediately upon starting. This would save you some fuss with window managers and locking down settings, if it only ever needs the browser... Sorry I cant remember which configuration file is involved. xsession or xinit, or similar?

Setting aside revocation, having your smoothie perform interception may be giving Java problems. I don't know what CA store Java references, but if it does not trust the Smoothwall CA cert then it could fail on that basis. Java may well share the Windows CA store - but software update processes often use their own list, or a self-signed certificate for which the software updater already has the public key. The way you can rule this out is to add a 'Do not inspect' rule to your HTTPS policy which will skip certificate checking and interception for these domains. That way your Smoothwall will not involve itself in the encrypted conversation. See how it goes if you add 'secure.oracle.com' into such a policy? My worry is that I have witnessed this same error at home - independently of any fancy networking.

I funny one this... I've seen it at home (Win7 64) following a recent Java update, but I don't (shh, don't tell anyone!) have a Smoothie at home. Aunty Google suggests this is a UserTrust issued cert, but I haven't confirmed that. If so, the revocation information that the error pertains to will come from crl.usertust.com or ocsp.usertrust.com. These shouldn't be hampered by Smoothwall (they're in the SSL/CRL category) and likewise they shouldn't to be dead or unavailable as it's a reputable CA. I wonder if there's something else going on, perhaps Java's certificate itself is bungled in the update?

Okay, there are two ways to approach this. The first thing I'd suggest is to look into HTTPS Interception. With this set up you'll be able to apply the header modification on both HTTP and HTTPS in just the same way. Or, as you suggest, you can block the HTTPS version entirely. You would have to do this with a URL regex, which can match the protocol. In many ways this is the poor cousin of "proper" interception - it's likely to break features on Youtube, and has a fair to middling potential to confuse your users. Feel free to follow this up in the Direct Support forum, or a PM, or contact our Support guys. I don't want to drag this thread too much OT

Hi skell, Forgive me if I'm being slow on the uptake, but what's your objective?

Fairly sure it's a HTTPS connection. You'll need some form of inspection to "see" the path and hence the extension. Alternatively, you might have one of the google domains set as an allow by mistake?

Oh, I forgot the 'how' bit: Providing you have the correct version of Android and you're connected to your hidden-SSID network, it's under Settings > Wireless & Networks > Wi-fi Settings. You need to hit the 'Menu' hard key to reach 'Advanced' -- it's in there somewhere.

Support for configuring a proxy was only added in fairly recent versions of Android. IIRC stock ROMs started supporting it around the time of Gingerbread (2.3?) for phones and Honeycomb (3.x) for fondleslabs. You can use transparent proxying for other versions of Android however. Also, if you're using Opera turbo that will make horrible socket connects that aren't HTTP at all. A Smoothie will block these connections like a proxy (as they are!)