been working with one of the boxes with the hotspot and setting up the walled garden to allow people to go pay the i have got most of the page to load but the pictures and the style sheet are not loading correctly so it does not look llike the paypals website any ideas of how to solve this ??

I suppose you addedhttp://www.paypal.comto your walled garden. But the PayPal website is loading all prictures fromhttp://www.paypalobjects.com, for example. So you have to add this to your walled garden, too.
The same holds true for the CSS files.

Best regards,
Christian Meis

The solution I found that works best is to do an nslookup on paypal then create mangle rules for all their IP addresses.

Trisc

The solution I found that works best is to do an nslookup on paypal then create mangle rules for all their IP addresses.

Trisc

So you have paypal working with walled garden hotspot w/mikrotik???

Mind sharing your setup?

I have paypal working in my walled garden by adding the following

allow - paypal.com
allow - *.paypal.com
allow - paypalobjets.com
allow - *.paypalobjects.com
allow - history.paypal.com
allow - *.history.paypal.com
allow - paypalssl.doubleclick.net
allow - *.paypalssl.doubleclick.net
allow - https://*.paypal.com
allow - https://*.paypalobjects.com

Some of them may not be needed and you might be able to do wild cards, but for me this works so I leave it alone.


The Reef

So now you have paypal accessible through the walled garden, but how are you allowing payment to then authorize Internet use?

What else did you have to do to get HTTPS to work I am working with WINBOX and I did the above such as you have posted for paypal except used our own internal server for the signup page yet it does not allow me to go to our server page???

Its like it does not like the HTTPS requests?

Thanks

I use freeRadius and Web server for the user authentication, management, payment and signup, I did add our servers to the walled garden and had no problem.

Try using the "IP List" in Walled Garden. This allows server by IP instead of by name.

Tried that but IP does not allow you to specificy HTTPS

doesn't matter. if you allow an IP then it won't matter what kind of traffic goes there, be it https or something else.

I'm running into a similar problem getting https requests to work through the walled garden. Works for some clients, not for others. Even adding in IP addresses, still a no go.

MT has issues with https in the walled garden. They may not like to admit it but there are issues.

I have it working but have to watch it all the time.

Do you mind sharing your workaround?

And, I agree, there are certainly issues with it...it can be hard to reproduce too.

One thing I am noticing when sniffing traffic on the router with the hotspot and walled garden - there are a ton of resends/retransmits happening. This is on a test network with ethernet and switches, so it's not likely to be related to the client's connection (my laptop on a switch).

Okay, so after much pain trying to solve this issue, I have discovered my problem. This may very well explain other issues people are seeing as well. I have verified several times that this is an issue only with 2.9, as 2.8.28 has never caused this behavior and proved to work fine on this network.

My simplified setup (ascii visio?):For this example and explaination, the follow IPs need mentioned:

192.168.1.100 - wireless client with problems
192.168.1.1 - client's gateway, ether2/hotspot IP which is NAT
10.0.0.2 - WAN on MT (ether1)
10.0.0.1 - LAN on DSL Router, MT's gateway

Again, the problem was that some people, including myself at one point, could not access certain parts of the https www server, even after entering it in the walled garden, by domain, IP, ports and protocols, etc - every combination there is, including also adding these to the pre-hotspot chains (which have proven to be less useful that we were hoping for) on both the nat and forward/input chains. Still, nada.

Sniffing packets at various locations only really should retransmits, but nothing more. So today I plopped in log rules in between most of the dynamic hotspot rules and discovered something strange. When the seesion stopped working, or never began and failed, I was seeing entries in the log. It started spitting out dropped packets with a src-address of 10.0.0.1 and dst-address of 192.168.1.100. The source IP is that of the DSL Router. When the session starts, the DSL Router never shows up as part of the connection (and shouldn't). But at some point, this breaks down and the packets appear to be originating from the DSL router instead of the web server. How can this be?

So, solving this was as simple as adding the DSL router IP into the walled garden. Now, everything works fine. This is one of the BritePort 4200 routers that Covad uses, which we have never had a problem with. We tested a 2.8.28 hotspot with an equivalent config, and didn't have this problem. We have fiddled with everything inside and out trying to figure this out including the conn-track settings (which seem a little too tight for default settings).

Is this caused by a possible failure in the connection tracking? Is there some other explaination for this? I could not reproduce this at home, which has a Actiontech DSL (NATed) router with my test gateway on the inside. If anyone could shed some light on this, it would much appreciated...while we've got things working, I'd really like to know why a next hop router should have to be entered in a walled garden *only* for https walled garden functionality.

If anything, I hope this may help other folks with similar issues

for what its worth, Im having suprious problems with paypal in the walled garden too. I was wondering if there was any comment from mikrotik folks on this thorny issue.

jm

In 2.9 just add all the IP addresses PayPal uses to your walled garden IP list. To use PayPal I simply create a payment button on the PayPal website, copy and paste this to hotspot login page.

The button code also redirects the user to a page of your choosing after payment is made. This should have a script that finds the next available login on your RADIUS database and displays this to the user.

Its very simple but you need to read the PayPal manual.