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

Suggestion.  Would it make sense to default with a web filter deny page with the ability to change to captive portal?  Currently it's kind of the opposite from captive portal to find a way to change to a web filter deny page.

Just a thought...

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

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?

Just tried a brand new XG for the first time (15.01.0 MR-2), apart from this very annoying and absurd issue, there are some other weird behaviours I had experienced before with UTMs too, like "sticky" NAT translations even if you _completely_ disable outbound nat _while_ you keep on pinging an outside host...
This said, why don't just default to a simple block page instead of trynig to offer at all cost a behaviour different from competition? What advantage in trying to authenticate everybody to get your block page soon after login?
Some people will not agree for sure, but my opinion is plain and simple, what is cheap is never worth it. PD

Hi everybody,

I had the same issue on our XG firewall with SFOS 17.5.3 MR-3. Since this thread is not marked as answered, here's my solution:

I had to disable Prompt unauthenticated users to log in feature

Additional I had to disable NTLM Authentication in the Device Access menue

Disabling NTLM Authentication is the only thing needed for this.

Basically if you have NTLM on, it is assumed that all clients are NTLM capable so it will try to authenticate with NTLM.  If that fails then it displays captive portal.  This ends up bypassing the Block Page altogether.

The "Prompt unauthenticated users of log in" controls whether the block page contains a link to log in (when the user is not authenticated).

The purpose behind both of these is that many companies have configured it so that authenticated users have more privilege to view sites than unauthenticated.  So if they hit a block page they should try to authenticate because after that the policy is re-evaluated and they may no longer be blocked.