Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Blocked site get the "Network Authentication" page instead of "Blocked Request" page...

Hi,
I just figured out to set the XG Firewall to used it only with Web Filtering.
Now when I have hit on a blocked policy, I'm redirected to the Captive Portal and I get the Network Authenticaion to login.
But I want to get the " Blocked Request" page and not the Network Authenticaion page.
How do I accplish this?
TIA



This thread was automatically locked due to age.
Parents
  • Hi All,

    Thanks for choosing Sophos.

    To give a denied page when a User tries to access a blocked website, you need to select NO in unauthenticated user redirection. If you select YES, XG will prompt Captive Portal to User(s). This is useful when you have defined web filter policy-user wise. Suppose User A has access to streaming media, alongside User B is denied the access to streaming media category, during such requirement the provided settings are quite useful. But with XG, I discovered that we lack the feature to configure the "User's applied policy" within a Firewall Rule>Policy for User Applications. So the workaround to get this feature work is to create multiple Group based Firewall Rule, where we can define granular filter options for respective groups. Hence, when a User receives a Captive Portal page and authenticates himself on it, XG will check the group association and take action.

    Hope this helps:)

    Thanks

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

Reply
  • Hi All,

    Thanks for choosing Sophos.

    To give a denied page when a User tries to access a blocked website, you need to select NO in unauthenticated user redirection. If you select YES, XG will prompt Captive Portal to User(s). This is useful when you have defined web filter policy-user wise. Suppose User A has access to streaming media, alongside User B is denied the access to streaming media category, during such requirement the provided settings are quite useful. But with XG, I discovered that we lack the feature to configure the "User's applied policy" within a Firewall Rule>Policy for User Applications. So the workaround to get this feature work is to create multiple Group based Firewall Rule, where we can define granular filter options for respective groups. Hence, when a User receives a Captive Portal page and authenticates himself on it, XG will check the group association and take action.

    Hope this helps:)

    Thanks

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

Children
  • But, the problem we are having is with Clientless Users.  I makes no sense to be directed to a login page when no login is possible ( no user accounts exist ).

    This is with "Identity: Match rule based on user identity" set to OFF in the policy.  So, if there is no checking for User Identity, why go to login page?

    The only workaround found is to add IP addresses (usually your entire LAN address space) to the Clientless Open Group and toggle each one to Active.  For some reason, that doesn't seem to work for everybody.

    Another thread about same issue:  https://community.sophos.com/products/xg-firewall/f/124/t/76445

    Am I misreading something? [:$]

  • Hey,

    for someone currently using about 50 SG units of almost all sizes, this webfilter setup is just plain weird.

    Why not have the block page get you that "unblock url" button with authentication option again like we do have it in the UTM world right now?

    For us who are planning on migrating to XG this change in setup is a major problem.

    Will this be adressed in a future release?