There’s still problems with captive portals that turning off “DNS Rebind Protection” off still won’t solve, and I think its only a 3.X software issue.
I was in a hotel a couple of days ago that had wired internet, and had it hooked to my Slate in “Router” mode. When I tried to log into the hotel’s portal, nothing came up with a “Can’t find address of host” error. I’d remembered the “DNS Rebind” setting, and turned that off, but it didn’t solve the problem. I put the Slate into AP mode, and from there I could log into the captive portal- but I had to do this for every device, which is what I’m trying to avoid via the use of “Router” mode (log-in once, use on all devices). So I took a look at the settings that the Slate was handing down between both the modes. The captive portal page resolved to 192.168.5.1 (but had an FQDN as the original page), and so was the DNS given if you connected directly (or in Slate’s “AP” mode). But regardless of the “Rebind” mode chosen, the Slate in “Router” mode always gave me a DNS of “192.168.8.1” (i.e., the Slate itself).
I think you guys are doing DNS caching(? or something) at all times when in “Router” mode- which is my theory of where the problem lies. When I manually switched the DNS server on my laptop to “192.168.5.1” and/or used https://192.168.5.1/login.asp when the Slate was in Router mode, I still couldn’t bring up the captive portal page (would either timeout, or say “can’t find address”). So what I think is happening is the DNS requests aren’t going directly to their DNS server regardless of the state of the “DNS Rebind” option, so either the remainder of the elements of the page are still trying to get their DNS from the Slate, or the DNS resolver at the hotel is seeing requests that it refuses for some reason. I ended up having to stay in “AP” mode the entire time, so everyone could see my devices on the network (last time I ended up on a hotel network without any type of NAT some joker in another room kept sending YouTube videos to my Fire Stick, so I try to avoid bridged mode when on public networks as much as possible).
As an added datapoint, my AR-750 (white, non-Slate) running the 2.72 software logged into this portal w/o issue just last month, so I think the problem lies in the 3.X software somewhere.
I won’t be back at that specific hotel for a while, but will be at another hotel soon and will keep an eye out for this issue. Please let me know what I should look for to help you diagnose this issue. My GL-iNet products are used 99% of the time I’m on the road and I need to be able to log in via any number of different captive portals.
Oh yeah, I even rebooted the Slate between changing the “DNS Rebind” setting (as well as unplugging/replugging the ethernet cable to the laptop) just to make sure the setting “took”.
I’m not sure I understand you here. But the topology in the “AP mode” case:
Hotel Ethernet->AR-750S->Laptop (via ethernet)
I also had my Fire Stick connected to the other port (via Amazon’s ethernet adaptor), and two phones and a tablet off the WiFi. Each device had to authenticate directly to the portal, but they were able to actually see the portal
Nope, pretty much straight out of the box; usually the only things I change are the admin password at first use and the WiFi SSIDs and passphrases.
In another thread, it was mentioned to perhaps add a manual IP entry for the hostname of the captive portal page. Barring any solution being posted here, if I end up in this situation again I’ll try that and post back.
Urgh. You’d called it, I just didn’t know. Turns out that when I was unsuccessfully doing my testing trying to get WG up and running, I’d left the VPN (client) connection state as “Enabled” when I’d powered it down, and forgot about it. A couple of days later when I was on the road, apparently the VPN client was still “Enabled” upon booting and since the WG server wasn’t working, no traffic hit the Slate’s router-mode clients. Putting it in AP mode also bypasses the VPN, so that’s why that worked.
How I’d discovered this was the problem was this weekend I was on the road again, and couldn’t get any client connectivity when in “Repeater” mode to a hotel WiFi that needed no authentication- so I dug into the settings then ssh’ed into the Slate, and couldn’t understand why the address of my potential WG server was in the output of ip route - it dawned on me that it was blocking traffic 'till it brought up the VPN (which I get), but the VPN wouldn’t have ever come up. Once I’d turned off the VPN I could get thru, and I’ll bet that I’d’ve had no problems with the portal page last week, either.
So, maybe this should go into the “Version 3 Bugs” thread, but perhaps we should record if a VPN connection was actually successful, and to not automatically bring it up on reboot otherwise.
