The problem
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.
The solution
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.
It is now possible to configure a remote workstation or laptop to enable the user to establish a VPN connection to the school’s network before logging in to the machine itself. In schools where staff are issued Windows devices to use away from school premises, administrators can configure such devices for the other staff.
The correct configuration would then allow the user to establish a secure connection to the school’s network even before logging into Windows. Once the secure connection is established, users will be able to log into the school’s domain which enables relevant scripts to run and mapped drive connections to be made.
The configuration must be made locally on each device and is currently supported for Windows devices only on post-Windows XP operating systems.
For full details on how to configure this setting please see the configuration instructions.
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
https://www.google.com/
is presented to the filtering system as a request for
https://173.194.67.105/
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
https://173.194.78.104/
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.
Since receiving their new LGfL 2.0 connections, many schools have been interested in testing their connection speed and running speed tests online as a result. However, obtaining accurate and meaningful speed test results is often not straightforward. The document available here offers a guide to running meaningful tests and interpreting the results.
Please note that to access the document you will need to log in with your USO credentials.