Posts: 7
Threads: 2
Joined: Sep 2020
Reputation:
0
(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).
Posts: 7
Threads: 2
Joined: Sep 2020
Reputation:
0
(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).
|
