Captive portal and HTTPS requests

I have the same issue.

We can't ask guest to install XG cert.

Any suggestion on HTTPS redirect to captive portal?

Hi All,

The certificate error is caused as HTTPS scanning is enabled in the FW rule to forward the hotspot client traffic to internet. Disable the HTTPS scan from the FW rule if certificates cannot be imported.

There is a HTTPS redirect option available in the diagonostics> authentication> authentication service> captive portal > redirect HTTPS. Enable this option to redirect HTTPS connections securely to captive portal.

Thanks

No! You give me the wrong issue.

I didn't enable HTTPS scan in all my rules.

We are talking about Captive Portal for users to identify.

Guests got certification error when they open the https website, and failed to redirect to Captive Portal.

But open http website can redirect to Captive Portal well.

HTTPS scan is not the issue!

Sachin,

What Shunze is saying is correct. Same thing for me!

Hello Luk

I was able to recreate this and getting the same behaviour. I was not able to get around this without trusting the appliance certificate. 

The only other workaround I could figure out at the moment was using hotspot, I read earlier in the post that this is a hotspot, so if hotspot and password of the day, or vouchers are enabled, the hotspot captive portal is shown instantly (HTTP and HTTPS). 

Hope it helps.

Varun,

Thanks for your response. Can you track it internally and give us a response ? I am not using hotspot (only have 3 customers do it).

This should work out of the box.

Thanks

HI lferrara, 

Its seems to be an  issue  when redirected to Captive portal page as the certificate is would not be trusted by the system at the start . So This occurrence are known to us ,  Could you all check if the issue is with Mozilla or also in Chrome and Internet explorer. If you have a service request opened in the past for the same issue kindly private message me with the link to this thread as a reference . 

Thanks and Regards

Aditya Patel 

Aditya,

I Tried to access https://facebook.com and what I have seen from the test:

• Firefox 49.0.2 on MAC: HSTS error and you cannot continue
• Safari: works
• Firefox 48.0.2 on Windows: works
• Internet Explorer 11: works
• Google Chrome 54.0.2840.71 on Windows: HSTS error and you cannot continue

Disabling HSTS did not help.

A feature request for this does not exist. On old Astaro.org bug like this were tracked as Mantis and then on community we knew the status (under investigation, fixed into version....).

We can use feature request, but for things that are not working, we need a feedback from you Guys in order to know the status.

Same thing for the Captive Portal (v16) where the network authentication page now is a link. It was working with v15.

If you want that we use feature request, please make sure to change the status on ideas.sophos.com, if you are evaluating them, if the feature will come into next release, build, etc..It is odd that only 5 feature request are under investigation at the moment!

Please provide a way to get people on community informed. Information are spread aroud and this is not a good feedback for community users.This is an example of how tracking bugs was easy and professional:

https://community.sophos.com/products/unified-threat-management/astaroorg/f/utm-9-2-beta/65664/9-200-bug-changes-to-ips-options/250355#250355

Please make sure to use the same Philosophy.

We are more than happy to be here and help you but we need feedback from you. There are many unresolved threads under v16 beta issues/bugs and we do know if they are fixed, will be fixed or...

Sorry if I have added this comment but I am here on the community everyday and I see that finding information or tracking bugs is not easy at all.

Hope that you and Bianson could improve the information and give us more feedback on know issues and their status and not only workaround.

Thanks

Hi Aditya,

I Tried to access https://www.facebook.com on V16, and all of following browsers can't work.

1. Chrome 54.8.2.840.71m
   
   
2. IE 11.321.14393.0
   
   
3. Edge
   
   
   
4. IE 8.0.6001.18702
   
   
   
5. Firefox 49.0
   

Aditya Patel said:

Its seems to be an  issue  when redirected to Captive portal page as the certificate is would not be trusted by the system at the start . So This occurrence are known to us

More and more websites are switching to HTTPS - and I support that, it's a good thing. But the captive portal does not keep up with that trend. It still uses an old fashioned way for redirection. The solution could be a redirection to the captive portal via HTTP (not HTTPS). How hard could it be to set the redirection URL to http://<applianceIPaddress>/<whatever> ?

The next step that I'm taking is to open up a feature request. I'll post the link in this thread later.

I found some interesting and disturbing feature requests.

First the disturbing one: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/16639819-automatically-displayed-captive-portal

The author complains about the change of connecting to a wireless network and he is right! The method in SFOS 15 was very easy to use. The change really makes no sense for an user friendly perspective. And I won't update to SFOS 16 as long as that hasn't be undone! That feature request will definitely get my support. (This change in SFOS16 is a real roadblock for non-technophile users.)

And now the interesting one: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/11580213-captive-portal-fqdn-support

Here is the suggesting to use a FQDN for the captive portal. That could work because we could get an official certificate for a FQDN (instead if an IP address). BUT the FQDN has to be available on the internet to get a certificate. This is the downside of this suggestion. You can't use an internal FQDN like https://portal.my.domain . Nevertheless this suggestion also got my support.

My feature request: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/16916704-captive-portal-redirection-via-http-not-https

You know what to do  ;-)

I found some interesting and disturbing feature requests.

First the disturbing one: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/16639819-automatically-displayed-captive-portal

The author complains about the change of connecting to a wireless network and he is right! The method in SFOS 15 was very easy to use. The change really makes no sense for an user friendly perspective. And I won't update to SFOS 16 as long as that hasn't be undone! That feature request will definitely get my support. (This change in SFOS16 is a real roadblock for non-technophile users.)

And now the interesting one: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/11580213-captive-portal-fqdn-support

Here is the suggesting to use a FQDN for the captive portal. That could work because we could get an official certificate for a FQDN (instead if an IP address). BUT the FQDN has to be available on the internet to get a certificate. This is the downside of this suggestion. You can't use an internal FQDN like https://portal.my.domain . Nevertheless this suggestion also got my support.

My feature request: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/16916704-captive-portal-redirection-via-http-not-https

You know what to do  ;-)