There are a several ways captive portals get a client to go to the portal:
One way is to make all HTTP traffic to a specific webserver, which then redirects you to the captive portal.
Another way would be ICMP redirection.
And yet another way is to hijack DNS to point the client to your captive portal.
All of them work different and each method deployed by the operator of the wifi-network may not work when settings on the client are not what that operator expected. Using another DNS-server may break some captive portals, while others might be fine. Each of the methods may have its drawbacks. For example if DNS records are resolved normally (but all HTTP traffic is rerouted), you may find someone doing some nice DNS-tunneling.
The GL Inet’s DNS resolver in the firmware probably also has DNS Rebind protection on by default (it should), which may also break some captive portals. (It may prevent local IPs in DNS results; That would break captive portals hosted on private IPs such as 10.0.0.0/8)
I’m not saying any of those cause the issues in this specific case, but it may have caused the reason why this specific captive portal did NOT want to load.