just a note, you can use <
tags to post exact code and phpbb won’t mess with it. now back to the topic…
www.paypalobjects.com and e120.g.akamaiedge.net have the same ip and TTL here. It is good for less than 20 seconds. Then it drops from the cache. If you (or a client) do another dns request immediately following the drop, it returns a new (different) ip. Now the old (previous) ip issued just seconds before will not pass through the hotspot. I explained this to support, and have not heard anything yet.
From my understanding of the walled garden, the destination ip of the packets must be in the dns cache list, and associated with a domain name to bypass the hotspot with a domain name. Twenty seconds after the dns request, those conditions are not met. Is there something else I am missing??
ADD: The intermittent part is: If you or a client does another dns request 40 seconds later, the old ip will now bypass the hotspot again. But the new ip won’t until another client does another dns request 40 seconds later. Did I mention the ip of www.paypalobjects.com is one of two ips, changing every 20 seconds. It just flip-flops between the two. Then after a few hours, the two ips change, but still flip-flop between those two every 20 seconds.
EDIT: It did not fail, but the “/ip hotspot walled-garden ip” removal does not remove the entry from “/ip hotspot walled-garden” as a dynamic entry, and also leaves the entry in “/ip firewall nat”. Use this at your own risk for now.
EDIT oct/14/2010: I am talking to support about the duplicate entries. They are looking into it. Otherwise, it is working great. Has not failed to bypass to paypal in two days now. I had to add one more domain in walled garden. The change is below.
Start of original post:
I used this code today without a single fail. Maybe you will have the same luck. I generated the PayPal standard account button and had no problem navigating to my payment page. I could log in but PayPal will not allow me to make a payment to and from the same account.
I used only these in
/ip hotspot walled-garden
add dst-host=www.paypal.com
add dst-host=www.paypalobjects.com
I entered this script as paypal. Run it once before you use paypal. Then schedule it once a day around 23:30:00 (11:30PM). Updates www.paypal.com ips and removes unused www.paypalobjects.com ips.
:local today [/system clock get date];
:local old [/ip hotspot walled-garden ip find dst-host=www.paypalobjects.com];
:local thisrem none;
:local thisip none;
:foreach i in=$old do={
:set thisrem [/ip hotspot walled-garden ip get $i comment];
:if ($thisrem != $today) do={
/ip hotspot walled-garden ip remove $i;
}
}
:resolve www.paypal.com;
:global paypalips [/ip dns cache find name=www.paypal.com];
:global oldips [/ip hotspot walled-garden ip find dst-host=www.paypal.com];
:foreach x in=$oldips do={
/ip hotspot walled-garden ip remove $x;
}
:foreach i in=$paypalips do={
:set thisip [/ip dns cache get $i address];
/ip hotspot walled-garden ip add dst-host=www.paypal.com dst-address=$thisip;
}
And I added this as paypalobj. Schedule it every 20 seconds. It adds any new www.paypalobjects.com ips it finds. You’ll need to remove the word wraps in a couple lines.
:global ppobjip [:resolve www.paypalobjects.com];
:local paypalobject [/ip hotspot walled-garden ip find dst-host=www.paypalobjects.com];
:local thisip none;
:local noip true;
:foreach i in=$paypalobject do={
:set thisip [/ip hotspot walled-garden ip get $i dst-address];
:if ( $thisip = $ppobjip ) do={
:set noip false;
/ip hotspot walled-garden ip set $i comment=[/system clock get date];
}
}
:if ($noip) do={
:log info "paypalobj script adding $ppobjip";
/ip hotspot walled-garden ip add dst-host=www.paypalobjects.com dst-address=$ppobjip comment=[/system clock get date];
}
My only concern is the additional entries in “/ip hotspot walled-garden”. When the old unused www.paypalobjects.com entries are deleted from “/ip hotspot walled-garden ip”, it appears to leave some kind of entry there.
Just a weekly update. 
If you use PayPal to collect money, I know now what makes the connection fail. I know the symptoms. First, you normally get a “connection cannot be established” message on your browser when you click the PayPal “Buy” button. Next, the “Buy” button will be a red ‘x’ with the same response if you click on it. ADD: One of the best fails I have been able to create is the PayPal payment page that was created by a third grader. If you time it just right, the browser can download the page, but will be unable to load the Cascaded Style Sheet (CSS).
First, the good part. 
I have not had a single problem going to PayPal since I started running this script.
Next, the bad part. 
The bug creating the duplicate dynamic entries has not been corrected. The duplicate dynamic entries will certainly crash my test router. It is only a matter of time. Even with only 17 ‘static’ entries in “/ip hotspot walled-garden ip”, I now have over 400 dynamic entries in “/ip firewall filter”, with no way of getting rid of them. A reboot does not do it. And the count goes up about 50 a day.
I just heard from Maris from support. The console on V3.30 is crashing, at least with this code. I must leave this version on this router for backup compatibility. I am ordering another router today. I will try this code on the new router. It will already have V4.x.
But even with the duplicate dynamic entries, not a PayPal fail yet!
ADD: Upgraded to V4.11. No change. Still duplicating dynamic entries.
OK! Now it works with no duplicate dynamic entries, thanks to Maris at support. You can’t use “dst-host” and “dst-address” in the same entry in “/ip hotspot walled-garden ip”. In V5.x, you will not be able to use both in the same entry. The scripts are in the wiki if you want to give it a try. Using these scripts, I have no fails to PayPal through the walled garden.
http://wiki.mikrotik.com/wiki/PayPal_with_hotspot_and_walled_garden_bypass
Wow, Thanks Tim,
This is great news. I didn’t know where to start . I’ve been getting customers with intermittent failed attempts at making payments via PayPal.
I’d called PayPal support. Of course they didn’t know what to suggest.
I’m going to run your script tonight.
I’ll try the fix.
P.S.
How’s the Shark population in Florida?
Hey oceanwifi! The problem was a bit difficult to find. It is a time-related issue. I know it sounds a bit backwards, but the PayPal problem is worse with fewer customers or, like me, at 2am with one person trying to purchase. If they hesitiate after going to the PayPal purchase page, like trying to go to another site. You know, try to hack by the login page. If they wait/try more than 5 minutes, they are doomed. The PayPal buy button is a red “X” and the link doesn’t work.
I don’t know about the sharks this time of year. I am a “fair weather surfer”. It is a bit cold for me right now. It will be late March before I get back in.
Oh yeah,
I can imagine now, they think they’re already on the internet as soon as they get to the PayPal site. Not knowing it’s “walled garden”.
I should probably post something on the login page like; “move right along now folks or you ain’t getting on”.
So, I’ve yet to load the fix you’ve come up with.
I’ll give it a go.
Thanks
I have been in contact with support about this several times. I think they may actually believe me now.
What I am hoping is a remake of the walled garden routine. I think the best would be to have something like
“/ip hotspot walled-garden address-list”.
When the original dns request is made from any client behind the hotspot that matches a domain in “/ip hotspot walled-garden”, it is inserted into the address-list for 1 day. Any ip in this list can bypass the hotspot. No need for my script. Great with me!
Really an incredible piece of work there SurferTim!
You’re saving alot of people (if they use this) alot of money.
Who knows how many people just give up and walk away.
I’ve been getting quite a few people telling me they can’t make the PayPal deposit. I have to add them manually then send them a PayPal request for money!
Geez, what’s it take for them to listen to you?
Upside is you’ve fixed it!
Thanks so much!
And how many internet-savvy users (like me, and probably you) won’t pay at all after that? They reason that if you can’t even collect their money without a problem, why should they trust the rest of your services? Bad news! And nothing spreads faster than bad news in a resort vacation community. Well, except maybe “something for free”. 
Excellent point. I’ know I wouldn’t think the operation (Hotspot) was very professional if they couldn’t manage the payments.
I’d walk.
Interestingly, a woman called the other day to tell me she couldn’t get past the PayPal site.
She wanted to get on badly enough to call. She’d queried me as to the security and how long I’d been up and running.
Again, between you, the guy that originally posted this issue, fewi and others, this was a really smart fix (is it temporary) to an obviously very difficult problem.
BTW. I added the script yesterday. So, it’s now running and, yep, I got a new customer early this morn. So far no problems.
Very Cool SurferTim!
Hope your compensated Well! 
Interestingly, a woman called the other day to tell me she couldn’t get past the PayPal site.
Actually, she couldn’t complete the payment at PayPal, because she too, had waited longer than 5 minutes before clicking the “submit” button on the payment page. A couple minutes of hacking and a few minutes finding her purse and credit card, then filling in the form, and now she can’t get through the walled garden to post the form to complete the payment.
ADD: Oh, and Santa, if you are still listening, and you think I have been a good boy, can you put the domain name the client requested in that address-list too?
You know what’s needed (other than your fix) is a flash timer on the signup page counting down the clock to let customer know they’ve got to get er done before such and such a time, or their going to be sent directly to Mikrotik support with a pre-filled out form stating they’re about ready to …
I prefer “You can’t hack this hotspot. You will have to pay. Take all the time you need to figure that out!”
I just got this from support. This is exactly why I use Mikrotik:
Hello Tim,
Thank you very much for your huge job and big efforts.
We have an idea to improve current walled-garden. It could be, that walled-garden
addresses are not removed from the list, but new ones are added by TTL to the
allowed table.
We will see how it will be possible to implement.
Regards,
Sergejs
Can’t thank you enough Tim
I’m definitely getting more “closings” now that you’ve helped with your script.
THANKS Very Much!
Thanks for your input. I have not received a single customer complaint about a PayPal payment failure since starting the script.
EDIT: It has changed.
Hello Tim,
Currently it is done in the describe way.
IP addresses are not removed from allowed /ip dns, but only new ones are added,
when client make requests.However, Paypal is the special case.
Could you try the rules for Paypal at v5.0rc4,
/ ip hotspot walled-garden add dst-host=“:^www\.paypal\.com$” dst-port=443
action=allow
/ ip hotspot walled-garden add dst-host=“:^paypal\.com$” dst-port=443
action=allow
/ ip hotspot walled-garden add dst-host=“:^content\.paypalobjects\.com$” dst-
port=443 action=allow
/ ip hotspot walled-garden add dst-host=*.akamaiedge.net action=allow
/ ip hotspot walled-garden add dst-host=paypal.112.2O7.netRegards,
Sergejs
I can’t use the beta V5.0rc4. Can someone verify this?
ADD: If it works like they say, this should do:
/ip hotspot walled-garden
add dst-host=www.paypal.com action=allow
add dst-host=www.paypalobjects.com action=allow
add dst-host=*.akamaiedge.net action=allow