08-31-2018 08:13 PM
Users who use Chrome as a browser, have been presenting problems in deploying the captive portal, looking in the Google forums they say that those captive portals that point to the IP 1.1.1.1 that to date it is a new DNS go to have problems and it is suggested that the manufacturers of these solutions use another address.
Therefore, what is AeroHive's way of modifying that the captive portal points to IP 1.1.1.1 without affecting its current functioning. Why in the AP230 equipment does the portal quickly unfold and in the AP250 there is a problem to appreciate it?
Solved! Go to Solution.
09-05-2018 01:43 PM
Hello everyone, finally the stabilization with the captive portal was given in the following way:
1. When the option "Use default network setting" is unchecked, the values that you must place there as suggested by AeroHive is to use 4 ranges of private networks that are not routed or are being used or in your local LAN and that are not routed networks in Internet, therefore in our case we used the networks that are specified in the graph
2. In the field "Web Server Domain Name" is an FQDN server name, for example if your domain is called xyz.com.co the name for example that would go there is webserver.xyz.com.co
3. In your local DNS it is suggested to create 2 type registers in the Forward zone corresponding to xyz.com.co with the first IP in the radius of 802.11a and radius 802.11b / g as the IP address, and both type A registers point to webserver.xyz.com.co
Temporarily depending on the technology of the wireless network card that the user has if it is 802.11n, it will receive a temporary IP 192.168.9.x and if it is 802.11ac it will receive an ip 192.168.8.x. Once you have authenticated in the captive portal, you will be assigned the IP with which you will be able to navigate or access the services of the network.
You can use any private ip range suggest for the follow RFC:
http://www.ietf.org/rfc/rfc1918.txt
http://tools.ietf.org/html/rfc3330
I hope this post helps everyone solve a problem
09-05-2018 03:31 PM
For step 3 of the post above, to give an example of what should be done, create a type A record in the local DNS point the name webserver.xyz.com.co pointing to the ip 192.168.8.1 and create another record type A with that same FQDN pointing to the ip 192.168.9.1
09-05-2018 01:43 PM
Hello everyone, finally the stabilization with the captive portal was given in the following way:
1. When the option "Use default network setting" is unchecked, the values that you must place there as suggested by AeroHive is to use 4 ranges of private networks that are not routed or are being used or in your local LAN and that are not routed networks in Internet, therefore in our case we used the networks that are specified in the graph
2. In the field "Web Server Domain Name" is an FQDN server name, for example if your domain is called xyz.com.co the name for example that would go there is webserver.xyz.com.co
3. In your local DNS it is suggested to create 2 type registers in the Forward zone corresponding to xyz.com.co with the first IP in the radius of 802.11a and radius 802.11b / g as the IP address, and both type A registers point to webserver.xyz.com.co
Temporarily depending on the technology of the wireless network card that the user has if it is 802.11n, it will receive a temporary IP 192.168.9.x and if it is 802.11ac it will receive an ip 192.168.8.x. Once you have authenticated in the captive portal, you will be assigned the IP with which you will be able to navigate or access the services of the network.
You can use any private ip range suggest for the follow RFC:
http://www.ietf.org/rfc/rfc1918.txt
http://tools.ietf.org/html/rfc3330
I hope this post helps everyone solve a problem
09-04-2018 06:46 PM
Remember that you can use any network segment that you are not using in your network to place in 802.11a radio and another segment in 802b / g radio, now if that segment you have there is blocked with the firewall, it is recommended that you do not block it.
09-03-2018 10:35 PM
Thanks for this topic. Recently ran into the same problem. After upgrading Hive Manager and setting additional IPs for CWP it was working for awhile. Now guest devices fail to access new IP, like 10.0.4.1
Found that the firewall policy for guest users blocks access to internal network by default (10.0.0.0/255.0.0.0)
Question: For guests to be able to see CWP on say 10.0.4.1 should I allow access in the firewall policy for guest users?
Thanks in advance.