redirect page for login

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
#8
(10-15-2020, 12:42 AM)momothecat Wrote:
(10-10-2020, 08:37 AM)benoit Wrote:
(10-06-2020, 01:14 AM)momothecat Wrote:
(10-02-2020, 01:15 PM)benoit Wrote:
(10-01-2020, 07:33 AM)momothecat Wrote: Hi Benoit,

Thanks for your response. So, for initial connection, user "must" access to KeexyBox IP address manually from their browser and there's no redirection mechanism.

What I mean in redirection is, for example; a user just enter any url in their browser and then the request redirected to the KeexyBox captive portal for authentication. After he/she authenticated, they can continue to access the internet.

If that function not in current version, maybe the developer can be so kind to add it in the future version.

Thanks


You should have a redirection. But maybe you had to disconnect from network and reconnect at client side to get it working.


Devices are redirected to KeexyBox Captive Portal if the client tries to reach one of these domains after accessing the local network:



connectivitycheck.gstatic.com

clients1.google.com

clients3.google.com

connect.rom.miui.com

captive.apple.com

airport.us

thinkdifferent.us

msftconnecttest.com

www.msftconnecttest.com



So it should works for Windows, Apple devices and Android.



What are your clients OS ?



For example we find out that XIAOMI phones do not use standard android URL (they use connect.rom.miui.com) to check if there is a Captive Portal on the network.

I'm sorry, it's look like I came to a conclusion too soon and not testing with other operating system. Earlier I was using CentOS 8.

After done some testing, here are the result with all the devices that I have in my home.

1. Windows 10
Initial connection: redirected to captive portal
Without authentication: not able to browse
Connection duration time out: not able to browse

2. iPad OS 13.7
Initial connection: redirected to captive portal
Without authentication: not able to browse
Connection duration time out: not able to browse

3. CentOS 8
Initial connection: not redirected, manual
Without authentication: not able to browse
Connection duration time out: not able to browse

4. Mi 11.0.6/Android 9 & Realme ColorOS 7/Android 10 & Vivo Funtouch OS_3.1/Android 7.1.2
Initial connection: redirected to captive portal
Without authentication: still able to browse
Connection duration timeout: still able to browse

For CentOS we need to find the address used to detect the captive portal. Once known, it is possible (since version 20.10.1 of KeexyBox) to modify the list of URLs by editing the "cportal_test_domains" param at http://keexybox:8001/config/advanced

It's strange for result 4, without authentication, you should not be able to use KeexyBox DNS...

I'll try to modify the captive portal config later for CentOS (other Linux OS).

In mean time, I reinstall the keexybox with the version 20.10.1 on the new sdcard and hope if the android devices redirection is fixed, but it's look like still the same. They still able to bypass access without authentication (DNS only mode).

I am able to reproduce the issue on my Android device. It looks to be a DNS over HTTPS (DoH) mechanism (called sometimes Private DNS or Secure DNS) that is implemented by default when DNS queries failed.
On my android I could resolve domain names and browse while KeexyBox was blocking DNS queries and private DNS was off on my device.
For a test, on my Android (Xiaomi) in "Settings -> Connection & share -> Private DNS" I had to set a fake hostname as the private DNS provider to really block DoH feature but by this way it make your device to never use DNS protocol even if DNS queries are allowed by KeexyBox or any available DNS on the network and you are not able to browse. So it is not a solution.
The problem is that the "off" option in "Settings -> Connection & share -> Private DNS" on the Android looks to have no effect to disable DoH.

https://support.google.com/android/answer/9654714

The only workaround I see is to use KeexyBox as gateway and DNS for Android devices, so it can also block HTTPS if user is not authenticated.
Reply
#8
(10-15-2020, 12:42 AM)momothecat Wrote:
(10-10-2020, 08:37 AM)benoit Wrote:
(10-06-2020, 01:14 AM)momothecat Wrote:
(10-02-2020, 01:15 PM)benoit Wrote:
(10-01-2020, 07:33 AM)momothecat Wrote: Hi Benoit,

Thanks for your response. So, for initial connection, user "must" access to KeexyBox IP address manually from their browser and there's no redirection mechanism.

What I mean in redirection is, for example; a user just enter any url in their browser and then the request redirected to the KeexyBox captive portal for authentication. After he/she authenticated, they can continue to access the internet.

If that function not in current version, maybe the developer can be so kind to add it in the future version.

Thanks


You should have a redirection. But maybe you had to disconnect from network and reconnect at client side to get it working.


Devices are redirected to KeexyBox Captive Portal if the client tries to reach one of these domains after accessing the local network:



connectivitycheck.gstatic.com

clients1.google.com

clients3.google.com

connect.rom.miui.com

captive.apple.com

airport.us

thinkdifferent.us

msftconnecttest.com

www.msftconnecttest.com



So it should works for Windows, Apple devices and Android.



What are your clients OS ?



For example we find out that XIAOMI phones do not use standard android URL (they use connect.rom.miui.com) to check if there is a Captive Portal on the network.

I'm sorry, it's look like I came to a conclusion too soon and not testing with other operating system. Earlier I was using CentOS 8.

After done some testing, here are the result with all the devices that I have in my home.

1. Windows 10
Initial connection: redirected to captive portal
Without authentication: not able to browse
Connection duration time out: not able to browse

2. iPad OS 13.7
Initial connection: redirected to captive portal
Without authentication: not able to browse
Connection duration time out: not able to browse

3. CentOS 8
Initial connection: not redirected, manual
Without authentication: not able to browse
Connection duration time out: not able to browse

4. Mi 11.0.6/Android 9 & Realme ColorOS 7/Android 10 & Vivo Funtouch OS_3.1/Android 7.1.2
Initial connection: redirected to captive portal
Without authentication: still able to browse
Connection duration timeout: still able to browse

For CentOS we need to find the address used to detect the captive portal. Once known, it is possible (since version 20.10.1 of KeexyBox) to modify the list of URLs by editing the "cportal_test_domains" param at http://keexybox:8001/config/advanced

It's strange for result 4, without authentication, you should not be able to use KeexyBox DNS...

I'll try to modify the captive portal config later for CentOS (other Linux OS).

In mean time, I reinstall the keexybox with the version 20.10.1 on the new sdcard and hope if the android devices redirection is fixed, but it's look like still the same. They still able to bypass access without authentication (DNS only mode).

I am able to reproduce the issue on my Android device. It looks to be a DNS over HTTPS (DoH) mechanism (called sometimes Private DNS or Secure DNS) that is implemented by default when DNS queries failed.
On my android I could resolve domain names and browse while KeexyBox was blocking DNS queries and private DNS was off on my device.
For a test, on my Android (Xiaomi) in "Settings -> Connection & share -> Private DNS" I had to set a fake hostname as the private DNS provider to really block DoH feature but by this way it make your device to never use DNS protocol even if DNS queries are allowed by KeexyBox or any available DNS on the network and you are not able to browse. So it is not a solution.
The problem is that the "off" option in "Settings -> Connection & share -> Private DNS" on the Android looks to have no effect to disable DoH.

https://support.google.com/android/answer/9654714

The only workaround I see is to use KeexyBox as gateway and DNS for Android devices, so it can also block HTTPS if user is not authenticated.
Reply


Messages In This Thread
redirect page for login - by momothecat - 09-27-2020, 10:20 AM
RE: redirect page for login - by benoit - 09-30-2020, 03:03 PM
RE: redirect page for login - by momothecat - 10-01-2020, 07:33 AM
RE: redirect page for login - by benoit - 10-02-2020, 01:15 PM
RE: redirect page for login - by momothecat - 10-06-2020, 01:14 AM
RE: redirect page for login - by benoit - 10-10-2020, 08:37 AM
RE: redirect page for login - by momothecat - 10-15-2020, 12:42 AM
RE: redirect page for login - by benoit - 10-20-2020, 04:22 AM

Forum Jump:


Users browsing this thread: 1 Guest(s)