Greetings!
I have found a quirk in the hotspot walled garden SSL handler. I have one site I experiment with, and have found that if you use the hotspot 1:1 nat, the walled garden will not let SSL packets through unless you put the IPs of the SSL sites in the “walled-garden ip” section of the walled garden setup. Since almost all in a SSL packet except the IP is encrypted, once the hotspot does the nat, it cannot read the packet url, and will not let the packet through the walled garden.
If the hotspot does not do a 1:1 nat, all works fine.
Bug or “working as expected”?
ADD: At least V3.13 (unlike V3.11) does not crash the login page when this happens now.
What is configuration for ‘walled-garden’, when HTTPs isn’t working ?
Hi sergejs
I use authorize.net to collect my money. Before I send my customer there, I collect some info, and assign user/password first.
So I use:
/ip hotspot walled-garden add dst-host=www.wififoryou.com
/ip hotspot walled-garden add dst-host=*.authorize.net
The first lets them select the number of days they want, and get their user/password in the database.
If the hotspot is doing a 1:1 nat (ie 192.168.2.4 issued by AP to 10.0.0.6 issued by hotspot) then I must use the IP addresses of authorize.net secure severs in “walled-garden ip” instead, or no payments.
Just to insure all is clear, clients can go to
http://www.authorize.net
fine. It is
https://secure.authorize.net
that generates the “page cannot be displayed” error.
If the hotspot issues the IP directly to the client, all works great.
OK, I was wrong. It just took a day to start. Now all SSL walled garden is failing unless SSL site IPs put in “walled-garden ip”, even if the hotspot issues the IP. RB433/V3.13 A sup-output is on the way…