Google Chrome Captive Portal Redirection

Hoping someone can shed some light on this issue and provide a possible fix/workaround. The issue is that Sophos is blocking sites that normally should be allowed. When you try to browse to www.google.com, you get the Sophos block screen. When you try to authenticate manually over port 8090 using the "Logon to this network" button, you are redirected to Chrome's captive portal page stating that "The network you are using may require you to visit its login page." If you click connect, you get another Sophos block screen for gstatic.com/generate_204. In the past, we could go into chrome://flags and disable the "Enable network service" option and this would solve the issue for most sites. It seems that this does not work anymore. This is only affecting users who are on a Citrix shared server with SATC running. For PC users, this isn't an issue. Has anyone else experienced this and if so, what did you do to fix it? I'm really not sure if this is a Sophos issue or a Google Chrome issue. Thanks. 

  • Captive Portal should not work for SATC (Citrix) Session.
    Simply because the Citrix Server has only one IP and Captive Portal is a authentication for IP to User mapping. 

    There is a issue with Chrome and SATC.

    Check out this:

    https://community.sophos.com/kb/en-us/133541

  • In reply to LuCar Toni:

    Yes, I have seen this before and like I mentioned, the workaround of disabling the "enable network service" settings in chrome://flags used to fix the issue for the majority of sites. Now, disabling this setting has no effect.

  • In reply to kgalloway:

    Would suggest to open a Support Case. Maybe the Flag is not set properly or something else. 

    As far as i know, this should resolve this issue.

    But if you have the same issue and the workaround does not work, you should contact the support to check your setup.

    Maybe the workaround is not valid anymore. 

  • In reply to kgalloway:

    Same here - as of Chrome 76+ it seems you cannot set 'runs network service in-process' via a group policy. (It's set in the policy/registry, but the flag is 'default' in Chrome).

    This means we cannot upgrade to the latest version of Chrome on Citrix. :7

    We can't ask users to manually set the Chrome flag either, that's not a workable solution.

    I hope there's a new workaround from Sophos, or even better, a new version of SATC that works properly with new versions of Chrome...

     

  • In reply to Rockfish:

    Are you using the Chrome Enterprise version? We actually had a breakthrough with this issue earlier this week. Since updating our image to Chrome Enterprise v. 76.0.3809.100 and enabling the Group Policy setting for 'runs network service in-process', all is well and users are no longer being blocked by Sophos when accessing sites they typically access.. I don't recall the version of Chrome that we were using prior to 76.0.3809.100, but enabling that flag had no effect. The group policy setting is located here - User Configuration/Administrative Templates/Google/Google Chrome/Force networking code to run in the browser process.  

  • In reply to kgalloway:

    kgalloway

    Are you using the Chrome Enterprise version? We actually had a breakthrough with this issue earlier this week. Since updating our image to Chrome Enterprise v. 76.0.3809.100 and enabling the Group Policy setting for 'runs network service in-process', all is well and users are no longer being blocked by Sophos when accessing sites they typically access.. I don't recall the version of Chrome that we were using prior to 76.0.3809.100, but enabling that flag had no effect. The group policy setting is located here - User Configuration/Administrative Templates/Google/Google Chrome/Force networking code to run in the browser process.  

     

     

    Thanks for the reply. I've grabbed the latest Enterprise version today (76.0.3809.132), installed it and checked under chrome://policy that 'ForceNetworkinProcess' is definitely applying.

    I have also checked my GPO settings are correct (same setting as you describe). If you look at chrome://flags, is #network-service-in-process actually set there? mine says default.

    I'm wondering if maybe the flags themselves don't change to display what's been set via policy..

  • In reply to Rockfish:

    I do see what you mean now.. I forgot that I manually set the flag for the user that I tested with. I set it back to default, refreshed GP, relaunched Chrome and it still shows default. RSOP and registry both show that it is enabled. 

  • In reply to kgalloway:

    Just for comparison, I checked on a Citrix server running Chrome 75, where this GPO setting still solves the issue and SATC works properly with Chrome.

    If you go to chrome://flags, 'Runs network service in-process' is set to 'Default'.  So the settings that can be applied via GPO appear to be unrelated to the flags, even if some of them essentially do the same thing.

    So we're back to square one - the only way to make new versions of Chrome function with SATC is by setting a flag, however you can't set flags for all users as they're considered experimental and not for Enterprise-wide distribution. Running the flag from shortcut (chrome.exe --network-service-in-process) doesn't seem to do anything either.

    I guess we'll just have to give up and wait for a new version of SATC. Crying

  • In reply to Rockfish:

    Setting this feature in GPO is still listed as a supported option by Google in the docs for Chrome 77, so it looks like the current problems are actually a bug in Chrome.

    https://cloud.google.com/docs/chrome-enterprise/policies/?policy=ForceNetworkInProcess

    This has been reported as a bug to the Chromium project here: https://bugs.chromium.org/p/chromium/issues/detail?id=1004179

  • In reply to RichBaldry:

    Rich,

    Thanks for that, good to know it's not a local issue or something i've configured incorrectly.

    I look forward to a new version of STAC that can work with the later versions of Chrome and avoid the issue altogether.   Yes

    RF

  • In reply to Rockfish:

    You're welcome. I checked on the bug report today and it looks like they've acknowledged the issue, so hopefully there will be a resolution before long.