Tested withMacbook pro m2.
Tested from network X with controller on network X
Tested from network X with controller on network Y
SSID with a password (standard), Hotspot enabled with a password. SSID with no password (standard), Hotspot enabled with a password.
SSID with no password (standard), Hotspot enabled with no password. All this:
All above resulted in
When I just access this URL internally, from any routable networks I see this.
Anything I can try?
We canât reproduce this internally so weâll need your help to gather information.
Can you provide developer console logs as well as the response to the /be/config endpoint in the Network tab (in developer console)? Also, have you tried Chrome?
-Jeff
Yes, I tried in Chrome as well same result. So strange you cannot reproduce, So I moved the AP to the cloud with the same setup. But no issues there. I moved the AP back now and tested it and the same issue is there again. I sent you a screen and the log files you requested in a PM.
I have one more update: I ran the Hotspot option on the local HW controller (1.0g) instead of using the external hotspot option, and the redirection is working fine.
Can anybody with a local HW controller replicate the issue with the Local hotspot failing on DNS lookup after the redirect?
http://192-168-15-66.3p05ioq543k.ouqtzq6XXXX.ddns.manage.alta.inc/hotspot.html
@CrowdControl I believe I was able to reproduce and fix the problem you were having, but I would love your confirmation!
If you look at the Network tab in Chrome, it was showing that there was a CSS and font file that were not downloading correctly, due to âNetwork issues.â We automatically allow portal.wur.eu because that is the external portal you are redirecting to, but the APs have no way to know which additional external dependencies may be required by that portal. I traced these with the browser, and after adding these to âAdditional Authorized hosts/IPsâ on my SSID:
I am now able to visit the external portal, as expected. Please let me know if you still have any issues.
-Jeff
Okay thanks, Jeff, for the external part it did work, but took a long time to load, probably because the above URLs were not allowed as you mentioned. I will test this tonight and let you know!
However, for the internal part, it redirects but the DNS URL is invalid. However when I enter this url on a non-hotspot network with the same underlying subnet. I got a response.
Please help clarify what you mean by the âinternal part.â What DNS hostname are you trying to resolve, and what is the expected resolution? Perhaps a video would help explain this better, because for me, your portal loaded and worked just fine as long as I added those two hostnames.
With internal i mean the local option under Hotspot:
.
Itâs the internal URL in the first screenshot I get redirected to but the DNS lookup fails.
However, when I paste this URL in my (incognito browser) when just connected to this subnet via another SSID on the same subnet and enter the URL, the lookup came true just fine. See also first post.
The local hotspot works via de cloud but I did not get it working with the HW controller.
I can confirm the external redirect loads blazing fast after adding the required external web URLs
@CrowdControl Great to hear on the external portal! For the internal portal, is it possible for you to run a DNS query manually to the APâs IP address?
The AP itself should be the DNS server in the case of both internal and external portals (i.e. it will intercept the DNS traffic and respond on behalf of any DNS server that is requested). You may need to use a different OS than macOS to test, though, because macOS will block all internet traffic until it has gotten past the captive portal login, OR you have told it to âuse the WiFi connection anywayâ even though it thinks there is no internet on that SSID.
Thanks for pointing that out â AP intercepts the dns traffic in this scenario.
And to confirm that logic by by-passing it, yes when I add it to the localhost file on my Mac, it works perfectly because it doesnât require the IP to be resolved through a DNS response.
For reference:
Client = 192.168.15.3
AP = 192.168.15.66
GW = 192.168.15.244
However, when I configure the DNS on my MacBookâs WLAN adapter to point to the APâs IP. I do receive a DNS response, but it doesnât include the necessary 'âanswerdâ information from the AP."
When I perform a lookup for google.com, I receive both the response and the answer message from the AP
When I perform the lookup to the APâs dns address, on a non-portal SSID but in the same subnet, I get the answerd back in the response.
So, is my MacBook blocking it, filtering out the answer message, or is the answer message never being returned? It looks like the AP send the answerd back because I can see that when I query the same on a non-portl netwerk but same subnet.
In any case, does this mean we canât use the local portal mode on a Mac and iPhone? Are there any workarounds or configurations we can apply on the local portal or AP to make it work?
@CrowdControl Iâm still unable to reproduce this exact issue here. Redirect to AP on a local controller works great with my Apple devices. The only thing I can think of is that you might have:
If this is the case, then the issue makes sense. Youâll either need to disabled DNS Rebinding protection, or unblock Secure DNS, or both. Otherwise, Iâd love to get remote access to the AP so we can understand why the DNS requests arenât making it out of the AP. The AP should be using secure DNS as a work-around, just in case you have DNS rebinding protection enabled. But if you follow the criteria above, the AP will not be able to look up its hostname.
I turned off everything on my firewall related to DNS forward binding etc. Interesting I cannot find anything in the DNS and Firewall logs related to this. My wifeâs Macbook and iPhone also donât work. I donât have window devices, only my parallel box, and that also complains that it cannot find the IP of the below DNS name. But since your Apple devices work I donât think itâs related to Apple. It just doesnât resolve the name
user@FBIVAN6-3 ~ % nslookup 192-168-15-66.3p05ioXXXXk.ouqtXXXX.ddns.manage.alta.inc 192.168.15.66
Server: 192.168.15.66
Address: 192.168.15.66#53
Non-authoritative answer:
*** Canât find 192-168-15-66.3p05ioqXXXX.ouqtzqXXXX.ddns.manage.alta.inc: No answer
I moved the AP back to the alta cloud now. The local portal also doesnât work there. But I am almost certain it did beforeâŚ
Action plan: since itâs now back into the Alta cloud Iâm going to move the AP to my parentâs place, to see if it works thereâŚ
@Alta-Jeff yesâŚItâs solved but you donât want to know howâŚ
So I plugged the AP at my parentâs place, and guess what the portal worked.
I came back to the office and plugged it in there (no changes happening) and it also works here now:
There is one thing I noticed and that is that the DNS changed to another one.
So the workaround for my problem is to attach it behind another internet connection so it starts changing the DDNS URL.
Hm, thatâs definitely interesting⌠if you want me to take a deeper dive, I would just need remote access to the AP while it is unable to resolve the DDNS hostname, so that I can debug why itâs unable to. Do you have the same router at both places?
If I can recreate the problem I will pm you to give you access. One side was Netgate (pfsense) and on the other side, it was an ISP modem.
