Are other people still having problems with this? Has any reliable workaround surfaced?
This is meant to be a sort of survey, so even if you have no info to offer, just reply saying yes or no.
No problem here. But that is vague. Are you having a problem?
ROS V3.11 with the transparent proxy disabled seems to be working.
ADD: I had a challenge with the redirect when I set the hotspot dns name in the setup, then connected the box to the internet and a couple of “real” dns servers. If that hotspot dns name is not a valid url, the redirect will fail.
We have a ‘splash’ page served directly from the router that then redirects to our web server. It’ll work fine for a while, and then just stop redirecting un-auth’d users to that splash page. My understanding is the transparent-proxy option applies to authenticated users; this problem occurs with un-auth’d users.
When it happens, un-auth’d users get either a general could-not-connect error in their browser, or an MT proxy error (the one that says ‘your cache administrator is…’). Reboots fix the latter (proxy error) issue. In the former case, though, even a reboot doesn’t fix things. I’ve tried using the default hotspot as well, with no customization, to rule out some sort of bad config in our stuff, but even that eventually fails.
That transparent proxy fault applies to all users. It cut off my un-authed users from connecting to Authorize.Net (walled garden) to pay me so they could get authed. That is very, very bad!
ADD: Here was the really bad part. It takes a day or two before it starts to fail. But when it does, it is GONE!! And that will be Friday afternoon…
I already have transparent-proxy disabled, btw.
I thought about the hotspot dns-name, too. But why would it work for a while, and then stop? The static entry is in the router’s dns cache, and the dynamic nat/fw rules are supposed to redirect un’auth’d dns requests to the hotspot.
I am not certain in your case, but in mine, setting the hotspot-dns-name=“” resolved the issue for me. This unblocked the login page failure, but not the walled garden fault.
So whats really going on here ?
We run multiple hotspot sites with exactly the same config on each, excepting some basic text for webpage titles and stuff, and redirect all hotspot logins to our webservers.
We are currently running ROS3.11 on routerboard 433’s.
All of sudden with no changes one system has failed to redirect and gives the use a proxy error.
We don’t have proxy enabled, or transparent proxy enabled on any sites, and never have, how can the user get a damn proxy error when the proxy is not even turned on ??
I have rebooted this unit multiple times to no avail, come on Mikrotik, we are running businesses from your equipment not toys, these problems just shouldn’t happen.
Has anybody got any suggestions on a workaround besides disabling the hotspot function and giving users unauthorised access ?
Regards
Paul
Same problem with failure to redirect to hotspot and cache administrator error messages. After three days of running perfectly on my 433AH (latest firmware, and ROS 3.11), I am feeling very bamboozled, and would wager a guess in saying this is a bug, since it does run fine for at least a couple days. It’s time for Mikrotik to step in and help. The sooner the better. Cold booting every day is not a solution I’m willing to live with much longer.
Cold booting hasn’t even helped mine, has anybody else got a workaround ?
Regards
Paul
Just to clarify where the bug is, and how to disable the proxy in question:
/ip hotspot user profile set default transparent-proxy=no
and set any other hotspot user profiles you created the same.
This is only V3.11 as far as I am aware.
MikroTik team assures me they are working on it.
The transparent-proxy setting is pretty well known around here already. Plus, the user profile settings apply only for authenticated users. If you have MAC-auth enabled on your hotspot, or if you manually pass-through a user, they’ll work just fine.
This problem occurs before a user can authenticate – there’s no disabling the proxy for unauthenticated users because that’s what’s used to catch requests to the hotspot. For unauthenticated users, the NAT rules redirect port 80 traffic to another port on which the proxy listens. And that’s where things break down. Sniffer sessions show some packets being redirected, but not all of them, and no response from the translated port on the hotspot.
These are EXACTLY the symptoms I had. To my extreme embarrasment, I jumped Authorize.net after sniffing a few packets, and got no response when the clients were supposed to go through the walled garden 
. My client were unauthenticated, and could not access anything (eventually) on the walled garden list. That appears to be enough to use the hotspot default user profile proxy.
ADD: I just completed a little experiment. I allowed Google and a couple other sites through the hotspot via the walled garden. It does not matter what the setting on “/ip proxy enabled” is (mine is set enabled=no), the hotspot uses it for the walled garden. Any 404 Errors have MikroTik HttpProxy and the webmaster setting. It is unaffected by the “/ip hotspot user profile” setting. Mine is “no”, but it looks as if it is still using the proxy.
Just a question for all here:
How many of you have SSL sites in your walled garden?
I have two V3.11 boxes. Both have SSL sites in the walled garden.
One box (RB333) has the SSL sites in
/ip hotspot walled-garden ip
after doing a nslookup on the servers,
The other box (RB433AH) has the SSL sites in
/ip hotspot walled-garden
I just checked them both, and here are the results:
The one with the SSL sites in “walled-garden ip” is still up and running after two weeks.
The one with the same SSL sites in “walled-garden” is crashed after two days. The SSL sites hit counts stopped a while ago.
Besides that, all is similar, including the proxy and hotspot settings.
I have the a couple SSL sites in there, but this is affecting people well before that even comes into play. The first page unauthenticated users should see is served directly from the hotspot itself. Sometimes they get nothing, other times they get the proxy error.
Same with me. The SSL sites are just the FIRST TO GO! The others follow in quick succession. I had NO login page at all (page cannot be displayed) on the “walled-garden” box, but logged in and paid on the box with the “walled-garden ip”.
I have now changed “Mr. Crash” to the walled-garden ip settings. Guess I will know in about three days. 
ADD: I have witnessed the deterioration of the login sequence. First, the SSL payment pages at Authorize.Net fail (page cannot be displayed). Then my prepayment pages start failing (page cannot be displayed). Then the login page fails (page cannot be displayed). But you gotta be there, It happened in a couple hours. Fortunately this time of year, I have enough clients that someone is going to call and say “why won’t you take my money?”.
Well the cold booting didn’t work for me, and I have to wait for the client to test the hotspot for me as it’s in another state so I can try the IP-Walled garden setting where I have added our auth servers into.
Has anybody come up with a method of testing the hotspot functionality from a remote location as yet ?
I was thinking of putting a PPTP server interface into the bridge we use for the hotspot but you can;t add that interface type into the bridge port list.
It would be nice to be able to test all of the functions of the hotspot remotely to see if was working.
Regards
Paul
Greetings!
I think it is time for a router check. My “2 week” box is showing signs that, without the “walled-garden ip” settings, it would have crashed this weekend. The hit counts in walled-garden after a counter reset two days ago:
secure sites = 0
clear-text sites = 674
The secure site hit count stop was the first indication of a failure.
BTW, it is still taking payments many times a day, despite the count. 
ADD: Here is the count from my “Day and a half” (Mr. Crash from previous post) box:
secure sites = 0
clear-text sites = 84
… and I just made a payment (test mode), then logged in, and no increment of the secure site hit count.
Two days ago, I could not even get a login page with this count.
Normis:
This is the walled-garden traffic over a 2 day period. This hotspot has taken a few dozen payments, according to Authorize.Net. Only this afternoon did any SSL traffic show up at all, and that was under the walled-garden ip entries. RB333/V3.11
[admin@HDMom] /ip hotspot walled-garden> pri
Flags: X - disabled, D - dynamic
SERVER METHOD DST-HOST DST-PORT PATH ACTION HITS
0 D ;;; secure.authorize.net
allow 0
1 D ;;; secure.authorize.net
allow 7
2 D ;;; verify.authorize.net
allow 3
3 X ;;; place hotspot rules here
allow 0
4 http://www.wififory... allow 694
5 secure.autho... allow 0
6 verify.autho... allow 0
[admin@HDMom] /ip hotspot walled-garden>
Note: entry 4 does not have the http:// in the entry. The forum software puts it there.
ADD: Here is a much more remote RB433/v3.10. It has taken about a dozen payments in the week this has been up:
[admin@hdroof] /ip hotspot walled-garden> pri
Flags: X - disabled, D - dynamic
SERVER METHOD DST-HOST DST-PORT PATH ACTION HITS
0 http://www.wififory... allow 175
1 secure.autho... allow 61
2 verify.autho... allow 35
[admin@hdroof] /ip hotspot walled-garden>
Note: Line 0 has no http://
The second one looks much cleaner, and a lot more accurate. Any way I can get that back in V3.12?
ADD 08/11/2008: Mr. Crash is still running fine, taking payments like crazy (I have made 4, including one just a few minutes ago just to check). But the traffic shows this:
[admin@MikroTik] /ip hotspot walled-garden> pri
Flags: X - disabled, D - dynamic
SERVER METHOD DST-HOST DST-PORT PATH ACTION HITS
0 D ;;; secure.authorize.net
allow 0
1 D ;;; secure.authorize.net
allow 0
2 D ;;; verify.authorize.net
allow 0
3 X ;;; place hotspot rules here
allow 0
4 http://www.wififory... allow 115
[admin@MikroTik] /ip hotspot walled-garden>
Nothing SSL at all.
Just an update. RB433AH/v3.11 “Mr. Crash” was working so well after 4+ days, despite the hotspot walled-garden clear-text site hits=134 and the SSL sites hits=0 after several payments (sure crash before), I re-enabled the transparent proxy on the hotspot. And, once again, it let me make a payment, and login. The only hit increase was the clear-text site. No SSL traffic hits shown. All still 0. Another few days and I will enable the transparent proxy on the busy hotspot.
Are you able to confirm which changes you made as I have added the IP of our server serving the login page and I still get the proxy errors.
Thanks
Paul