Issue with hotspot redirect to captive portal

  • 1
  • Question
  • Updated 3 weeks ago
I'm having trouble with the hotspot redirect to captive portal for authentication.

I have a Guest VLAN 201, where it's able to redirect properly. When a client connects to the Guest SSID, my firewall provides an IP address via DHCP and also a dns cache entry to point to the ZD's IP address. This works perfectly fine.

However, when I try to set up a hotspot VLAN 202, my wireless client which gets an IP address via DHCP and the same dns cache entry to point to the ZD's IP address, is not able to redirect. It seems that it can't reach the ZD IP. When i do a netstat -n on the cmd, I see a SYN_SENT to the ZD IP, but it's not getting a reply.

I've configured my VLAN settings for both 201 and 202 the same on my firewall. They both have DHCP and DNS configured the same.

On the ruckus configuration, I have the Guest VLAN on Guest Access type and the Hotspot VLAN to Hotspot Service type.

What doesn't make sense is when I change the Hotspot VLAN from 202 to 1, my wireless client is able to access the captive portal redirect successfully, but it's not on the correct network. It's actually accessing my internal network which I do not want and it gets an IP address on the same subnet the ruckus acess points are on.

Any ideas why I am able to redirect properly on the Guest but not on the Hotspot? Pretty sure it's not a firewall issue as both vlans are configured the same and they are in the same ruleset.
Photo of pyoonit

pyoonit

  • 6 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Sander Groen

Sander Groen

  • 15 Posts
  • 0 Reply Likes
Hi, perhaps you have a whilelist in place for the guest WLAN and need to add the IP/MAC of the DHCP server?
(Edited)
Photo of Harry Bells

Harry Bells

  • 1 Post
  • 0 Reply Likes

There's one thing the captive network can't do: Redirect to its own page while returning the correct server certificate. In principle, there are those possibilities: (a) not redirect https at all. (b) redirect with a self-signed certificate. (c) return its own certificate, so https negotiation will fail. (d) immediately kill any connection attempt with https.

Since switching networking code on iOS from http to https, I found more than one captive network immediately killing any connection attempt. That would be a rather strong indication to an application that there is a captive network. The application can then use better detection by visiting one of Google's or Apple's URLs that are provided for this purpose and if they don't respond as expected, then you definitely have a captive network. The application can go from there and launch a browser or let to user go to settings.