Category: Internet access

issues with Chromebooks connecting

We have received reports that Chromebooks are struggling to connect to the the internet.

It appears that if the Chromebooks are connected to the transparent proxy. Or if they use the no SSL proxy settings, they connect fine. It appears to be connected to SSL inspection.

This has been passed to RM to investigate…

Thanks all.

Proxy issues?

In the early hours of this morning, RM engineers added some new SafetyNet Load Balancers into service. This was planned maintenance work to ensure the service remains stable. We have received some reports this morning advising us that there are problems browsing the internet today. This is back with RM who are investigating…

I’ll add another update shortly.

Thanks,

Kevin Crawley

Websites that use websockets – Chromebooks

When using Chromebooks, you may experience issues accessing websites that use websockets. In these instances, the browser on the Chromebook attempts to go out to the internet using the SOCKS protocol entry from the proxy settings.

Normally sessions go out to the internet using the top 3 protocols (HTTP and HTTPS especially). Other devices (Windows etc) have the SOCKS protocol blank so it will send the session to the internet via HTTP/HTTPS instead. On Chromebooks if you’ve set a proxy (wf1.thegrid.org.uk etc) via G-Suite it ticks it for all protocols (including SOCKS). However, RM do not support the SOCKS protocol and this makes the outbound connection fail.

There are some high profile websites that use websockets such as SCOMIS, Spotify, and LiveStorm. It may also cause issues when using the remote desktop web client into a LARA server.

There are a couple of fixes!

Option 1) remove the entry from the SOCKS protocol, and leave it blank.
Option 2) schools connect the Chromebooks to a transparent proxy network (typically a 10.* range), instead of the proxied network (172.* range)

If you have any queries, please get in touch with our Service Desk. Thanks

Google issue from 29th January

Following on from the Google search issues that occurred last month, RM have provided HfL with a report on this incident.

Report Summary 

On 29th January 2019, users reported issues accessing Google search results when using SSL proxies (wf3.thegrid.org.uk etc.). While trying to access search results, users were not receiving the desired webpage, instead they were getting a filtered message.

When dealing with a non-Herts eSafety query, the RM Service Desk added a new deny rule into the RM Global List (RM Pornography) within RM SafetyNet. This resulted in denying all the Google URL’s containing the rule. The change was applied to the live environment after being tested. Whilst the initial rule was overly broad, it was implemented quickly with a safety first approach as the video on YouTube was of a highly offensive nature. Following analysis and fault detection, this entry was updated to a more surgical approach, allowing for normal google search access to resume.

Follow-On Actions: The RM Management Team will discuss and finalise further safety measures that needs to be taken when staff amend the RM Global Lists. RM Management will also review the current testing scenarios and propose amendments if required.  Additional training will also be delivered to the RM Service Desk and they will be reminded of the importance when amending rules on the RM Global Lists.  HfL have requested RM keep us updated on developments.

Google update

My understanding is that when you try and browse to a HTTPS site through a Google search – the search will not load. If you type the HTTPS site straight into the browser – the page loads. Also if you disable SSL inspection – and use the nossl proxy settings, I think all works correctly (but SSL inspection is of course turned off then).  Proxy settings:

https://hfl-broadband.co.uk/other-technical-services/proxy-settings/

RM are working on this and they believe that Google may have changed something at their end, causing this problem to occur. Naturally this remains high priority with RM. Thanks