A new LGfL wireless network has been rolled out to all public libraries within Richmond as of March 2014. The managed wireless solution uses LGfL’s WebScreen 2.0 filtering system and offers pupils and staff from local schools flexible internet access by providing web filtering designed for them by their own schools.
Configuration of filtering policies takes place within the schools and is automatically activated in the libraries through the per-user filtering feature. To benefit from the service, students and staff need to simply use their existing LGfL USO user credentials and log into the system. This filtering will automatically cover the mobile devices of everyone with a USO account connecting to the libraries’ wifi. The actual filtering policies covering each user will be set up and managed by the schools. Adult users without USO accounts will be able to obtain access on request from library staff.
This system makes filtering management simple for library staff and ensures that all users who can be identified by their schools can bypass local filtering settings and obtain the degree of access they would normally be accustomed to at their schools.
Full details on creating the correct configuration are available in the USO Support Site User Guide.
If you would like to know more about using the LGfL managed wireless system in your own establishments please email firstname.lastname@example.org or call 01689 814700.
Using Google search will often take users (unknowingly) to the HTTPS version of their search engine. This changes the search experience as the data and content become encrypted, making it hard to filter against content or key words using filter systems such as WebScreen 2 and prevents the Google Safe Search function from being enforced.
If you wish to disable Google searches from taking place in an HTTPS environment so that filtering rules can be enforced along with Safe Search, you can do so by using the DNS servers in the core of the LGfL Network. These have been configured to ensure that any request for https://www.google.ee is redirected to a non-HTTPS version of the Google site in the locale requested. This means that for example if a user trys to surf to https://www.google.ee/ they will always end up at http://www.google.ee/
This DNS redirection does NOT affect other Google systems such as Gmail, to which secure access is still available.
In the LGfL 2.0 network, the LGfL core DNS servers located at 172.30.178.53 and 172.30.178.54 can be used to perform this redirect for Google, in other broadband networks use your core DNS servers.
If you do not wish to make use of this service and wish to run your own local DNS then you can point them at root DNS servers on the internet which are NOT blocked on your network by default.
If you wish to completely secure your school’s network then please raise a support case and ask for all non-core DNS requests to be blocked through your local firewall. This will prevent local users from changing the DNS servers they are using away from the core servers.
In an environment containing machines running Windows XP, users may have had difficulties accessing LondonMail when using certain browsers. This issue is related to the blog post below regarding access to secure sites using Windows XP.
In order to grant access to LGfL-supported Microsoft services such as LondonMail, the relevant WebScreen 2.0 filtering policies need to have the Microsoft IP ranges added to the Allowed URL and keyword lists in those policies.
It is important to note that if you have previously allowed the category “Host is an IP” in your policies to overcome problems with accessing LondonMail, then you may wish to consider blocking this category once more to ensure maximum control of access to sites which may be accessed via IP addresses rather than more conventional URLs.
For full details and a list of the required IP ranges please see the WebScreen 2.0 FAQs section found in the Support Site User Guide.
Due to the way Microsoft XP interacts with various browsers, users of Internet Explorer, Chrome or Safari browsers on a workstation running Windows XP, are likely to experience an issue when trying to access https sites. Only this particular combination of technologies is affected due to the way Microsoft handles https sites in XP. Please note that Firefox users will NOT be affected in the same way as Firefox bypasses the built-in Microsoft XP routines. There are also no issues with any of the browsers in combination with a later version of Windows. The best long-term solution is to upgrade workstations to a later version of the operating system or use Firefox as the default browser.
Under XP, when browser requests to https sites are sent using the full standard URL, the URL gets translated to the IP address of that site before it reaches the filtering system. Access to the site may then be denied unless the IP address has been explicitly allowed.
For example: a request to visit
is presented to the filtering system as a request for
Further complications may arise when destination sites have multiple IP address possibilities as they are hosted on multiple servers. So the above example could appear as
depending upon the address to which the URL translates at the time.
As a result, to ensure that an https site is allowed/blocked correctly for those using the XP system with one of the affected browsers, the URL and any IP addresses belonging to the site should be added to the appropriate filtering policy. This approach is effective in situations where target websites are hosted on single IP addresses that can be identified relatively easily, either by pinging the target URL and making note of the IP address returned or by a careful examination of the reports available under the Webscreen 2.0 interface on the USO support site.
It should be noted that although the category “Host is an IP” can be allowed, this results in any https site becoming accessible.
Major changes to the way the Youtube safesearch facility operates (implemented by its owner Google) have meant that, for the last few months, it has not been possible to enforce Youtube safesearch through filtering policies configured in WebScreen 2.0. Safesearch could be configured within the Youtube site but this would have to be done on an individual basis for all users.
However, we are pleased to announce that, as of 8 March 2012, work carried out by Atomwide and its technology partners once again makes it possible to enforce safesearch within the youtube.com site by switching on the safesearch functionality within the relevant filtering policy.