I have a GLiNet AR750 Slate travel router which works perfectly well, I take it on all my travels and never have any problems, until I arrived at this hotel in Greece...
I can resolve the pointer.spothub.io fine on my laptop (DNS rebind protection is disabled already), and tcpdump on the router shows that the https requests to the captive portal are sent to WAN and a response is received, but the router does not forward that response to my clients, so I never even complete the TCP handshake for the captive portal.
Now here's the crazy thing.... if I try to access pointer.spothub.io on http/port 80, I can complete the TCP handshake as the reply traffic is returned properly by the router.
If I connect the travel router to my mobile phone hotspot, all https traffic works perfectly and I can even access the captive portal site pointer.spothub.io using https.
If I connect my devices directly to hotel WiFi, these also work fine and the portal is reachable on https.
I am starting to question my sanity and position as an IT network engineer!! What possible reason could cause my travel router not to forward reply traffic back to the client, but only when using port 443 on a specific hotel's WiFi, and a specific website?? I can't even say this is https related as I don't complete the TCP handshake. And also strange that the initial site hotspot.spothub.io works fine.
All client devices have a built in captive portal detection (CPD). This tests for a captive state by sending a port 80 http request to a specific probe url. The ip address has to be resolved and the reply for a non captive connection will be something that is checked for to determine if the connection is open or captive.
If the captive portal is blocking all but its own dns resolvers ( as it should - but many captive portals do not), then if your travel router does not use the captive portal's dns resolver the result will be what you get.
Let your travel router use the upstream dns as given to it by dhcp rather than overriding.
Yes it is set to use the DNS server assigned by WAN DHCP.
But I don't see this as a DNS resolution issue - my problem is that the captive portal sends a SYNACK which is received by my travel router but not routed (natted) to my client.
But I can only recreate this issue on port 443 and only when using the hotel wifi. This makes zero sense to me.
Yes, that's it!!!! Responses on port 443 are arriving with TTL1 but port 80 is TTL127
So this must be to avoid people being able to use intermediate routers in this way..... hopefully there is a way I can re-write/ignore the inbound TTL to allow the packet to be forwarded??
Yes indeed, I have fixed the issue by adding this to the custom iptables rules...
iptables -t mangle -A PREROUTING -i wlan-sta -j TTL --ttl-set 64
Thanks for everyone's help. I never considered that providers manipulate TTL for such reasons. But now my eyes are open and I also manipulate TTL to beat them at their own game
