Web policy block page not loading

Some Context/Info:

In Administration > Device Access each column corresponds to opening up a port.  In "Captive Portal" corresponds to port 8090, and in v15 that is all it did.  However port 8090 is actually used for several other things in web as well, including Warn/Proceed (introduced in v16) and Sandstorm (introduced in v16.5).  In v18 port 8090 is also used extensively by the DPI mode proxy.  The column header "Captive Portal" is increasingly misnamed as it is actually enabling many different things.  We are aware that this is confusing and are looking at our options.  This might be renaming the column, or it might be splitting between multiple ports/columns.

In conclusion, if you are using any of the following features, you need to enable Captive Portal within the relevant zones:

• Captive Portal
• Web Policy "Warn" action
• Sandstorm within Web Filtering
• DPI mode within Web Filtering

Hi Michael,

To clarify, on other threads it has been commented by Sophos staff that separation of the captive portal from the Web proxy/alternate services will be looked into.

Is this still on the books?

Emile

Yes.  I was in a meeting about it last week and we estimated that it would be difficult to do for v18.0 GA.  There is significant regression testing around any change for this.  So I can confirm that we are aware of it, but I make no assurances if it will be fixed or when.

Hi Michael,

Thanks for the update. I'm guessing the captive portal webserver and the other elements are laced into that?

So it's not a case of just moving the captive portal onto, say, 8091 and it would have to be unpicked from all the other elements?

Emile

Unknown said:

Thanks for the update. I'm guessing the captive portal webserver and the other elements are laced into that?

So it's not a case of just moving the captive portal onto, say, 8091 and it would have to be unpicked from all the other elements?

There are several options.  One option is just to rename the column.  One option is to start using another port and add a new column for it.  One option is to start using another port, but add it to the existing "web proxy" column.  Is there a fundamental reason for separating Captive Portal from other services?  Or for separating DPI mode?  If we create a new port and we have four distinct functions, which ones should be grouped on same port.  Each choice has different upgrade implications.  Also important for timelines, is how many different teams need to coordinate to make changes.  The change itself is probably small, but how many different things need regression testing.  If we are changing what ports we are opening, are there security implications and do we need new external audits.

What we know right now is that we did not think that it would be a major issue (except confusion) to customers to put a checkbox beside Captive Portal.  The checkbox in on by default and we know most customers that use web have it enabled.  That being said we are getting feedback in EAP, enough that we are looking at it.  Any change (aside from simple rename) is too big for v18.0 GA.

P.S. Port 8091 is already used, it is the next column over.  In v17.5 it is NTLM and in v18.0 it is AD SSO.  This is because both NTLM and Kerberos use port 8091.  In this case it made the most sense just to rename the column.

Unknown said:

Thanks for the update. I'm guessing the captive portal webserver and the other elements are laced into that?

So it's not a case of just moving the captive portal onto, say, 8091 and it would have to be unpicked from all the other elements?

There are several options.  One option is just to rename the column.  One option is to start using another port and add a new column for it.  One option is to start using another port, but add it to the existing "web proxy" column.  Is there a fundamental reason for separating Captive Portal from other services?  Or for separating DPI mode?  If we create a new port and we have four distinct functions, which ones should be grouped on same port.  Each choice has different upgrade implications.  Also important for timelines, is how many different teams need to coordinate to make changes.  The change itself is probably small, but how many different things need regression testing.  If we are changing what ports we are opening, are there security implications and do we need new external audits.

What we know right now is that we did not think that it would be a major issue (except confusion) to customers to put a checkbox beside Captive Portal.  The checkbox in on by default and we know most customers that use web have it enabled.  That being said we are getting feedback in EAP, enough that we are looking at it.  Any change (aside from simple rename) is too big for v18.0 GA.

P.S. Port 8091 is already used, it is the next column over.  In v17.5 it is NTLM and in v18.0 it is AD SSO.  This is because both NTLM and Kerberos use port 8091.  In this case it made the most sense just to rename the column.

Appreciate the info. I would think at a minimum it would be useful to be an asterisk next to "Captive portal*" and below the table, put a note that this particular options controls more than just the captive portal with a link to the help file. Additionally, I've always thought the help file was pretty lacking when it came to explaining Local ACLs so updating that with the information you provided would be beneficial. With those two things combined, I think it would be fairly clear to a user.

Agreed, just a note that it is a need for End User pages would be helpful as that has come up several times in the EAP.

Michael, thank you for the info and quite right I picked a port off the top of my head!

Emile

A sneak peek at the future.

I realize this is extremely picky but my two cents:

• Put an asterisks in front of the statement (e.g. * Turning off access to...)
• Reword to "Turning off access to captive portal also stops user notifications from appearing..."