I need help in Mikrotik hotspot setup. For scenario diagram please refer attached file.
I am connecting Mikrotik router to Antamedia Hotspot. Which is serving as radius server to mikrotik router. Everything is working fine except walled garden in mikrotik router. I have added several urls to walled garden of mikrotik. Some of them are HTTP based and some are HTTPS based.
Example: http://www.abc.com (works on http) and http://www.xyz.com (works on HTTPS)
Both the urls should work without going to hotspot (for RADIUS authentication) as they are added to walled garden of mikrotik but http://www.abc.com is working but http://www.xyz.com not working.
I have tried different URLs and found that the urls with HTTPS protocol do not work.
Where is the problem? Please help

56 views and not a single solution?

I believe nobody here is an mikrotik expert...

Hello
Usually posting an export of the configuration helps people assist you better.

I'm just guessing at this point but did you enter the above hostnames on Walled Garden or Walled Garden IP List?
Also, are you using tcp - 443 for the https?

Try the following command (works for me for google.com)
/ip hotspot walled-garden ip add action=accept disabled=no dst-host=www.xyz.com dst-port=443 protocol=tcp

I have found this problem in my tests with version 6.36 and 6.37.

What I have discovered (replaced original domains ) :

http://www.xyz.com works
https://www.xyz.com does not work

the walled garden have the www.xyz.com host with allow entry.

Currently the www.xyz.com is not an A record in DNS but an CNAME record.
www.xyz.com CNAME to www.kkk.com

when I put www.kkk.com in walled garden I can access using https.

I have seen also that the number of hits in walled garden does not count on www.xyz.com just on the final CNAME record www.kkk.com

In my mind when the user request www.xyz.com the hostspot dns system should check for the first name and not just for the last one,, appear to be a bug in the hotspot system.

In my mind when the user request http://www.xyz.com the hostspot dns system should check for the first name and not just for the last one,, appear to be a bug in the hotspot system.

This doesn't matter for CNAMEs.

The reason is simple:
1) https is encrypted, so the hotspot cannot monitor for URLs being grabbed - this is why SSL requires IP-based walled garden control.
2) If a name you enter is a CNAME (not an A record) this doesn't matter - it must eventually lead to an IP address, and it's the IP that gets blocked, not the name.
2) as long as the blacklisted CNAME points to something that points to the same IP address, then the block will work.

The problem that DOES happen with CNAMES is that the IP gets blocked no matter what name it's called by.
Suppose bad.com -> web.hosting.com and good.com -> web.hosting.com
In this case, the Walled Garden will block the IP of web.hosting.com , so even though you might want to allow good.com, while blocking bad.com - this is not possibly by IP address, because both names resolve to the same IP address, and this is the same whether the RR is a CNAME or an A record.

There are some reasons it might not completely work that aren't directly related to CNAMEs. If a site's DNS does global load balancing or any other kind of fancy stuff where different requests get different replies based on some criteria, then your user's request for bad.com might just receive a different (set of) IP address in the reply than the Mikrotik did whenever it performed its own query. The way to combat this possibility is to force users to use the Mikrotik as their DNS server (either assigning it in DHCP directly, or by transparently redirecting DNS queries to the Mikrotik with a DSTNAT rule). That way, they're forced into having the same exact view of DNS upon which the IP policy is based.

I understand that mikrotik cannot lookup inside the packets to see the real request destination by Host header.

But the hotspot code can have an option to check the DNS resolutions (yes All DNS resolutions are being made by the mikrotik) and when there are an resolution for a name in walled garden follow the entire resolution and consider the IP as permitted.

name1 CNAME name2
name2 A 4.3.2.1

if the name1 is in walled garden as permitted, and was resolved by the mikrotik hotspot DNS the IP 4.3.2.1 can be permitted.

Of course if a bad site points to the same IP (directly or by cname) the user will have access to bad site.

But this currently are possible when the sites use directly A and the connection is made using https.
www.good.com A 1.2.3.4
www.bad.com A 1.2.3.4

You are correctly also for the case of ballancing, but if the hotspot DNS check the resolution the IP will be cleared in the walled garden.

If two names with different rules resolve to the same IP, then what do you expect the Mikrotik to do?

have you got hotspot login https enabled? you also need to create a self signed certificate before that. try and check if it works.

If two names with different rules resolve to the same IP, then what do you expect the Mikrotik to do?

Considering that it connect check inside the https , it should permit both names, because the IP is permitted.

I understand that mikrotik cannot lookup inside the packets to see the real request destination by Host header.

But the hotspot code can have an option to check the DNS resolutions (yes All DNS resolutions are being made by the mikrotik) and when there are an resolution for a name in walled garden follow the entire resolution and consider the IP as permitted.

name1 CNAME name2
name2 A 4.3.2.1

if the name1 is in walled garden as permitted, and was resolved by the mikrotik hotspot DNS the IP 4.3.2.1 can be permitted.

Of course if a bad site points to the same IP (directly or by cname) the user will have access to bad site.

But this currently are possible when the sites use directly A and the connection is made using https.
http://www.good.com A 1.2.3.4
http://www.bad.com A 1.2.3.4

You are correctly also for the case of ballancing, but if the hotspot DNS check the resolution the IP will be cleared in the walled garden.

Maybe that's how it happens, but it's not the best way.
Maybe that's why I'm having multiple domains of google released incorrectly.
Today, HTTPS requests use TLS and browsers support SNI existem, in which the name of the server is sent.

Https://en.wikipedia.org/wiki/Server_Name_Indication

Can you confirm mikrotik with this information? Can we disable DNS resolution and use SNI?

Maybe that's how it happens, but it's not the best way.
Maybe that's why I'm having multiple domains of google released incorrectly.
Today, HTTPS requests use TLS and browsers support SNI existem, in which the name of the server is sent.

Https://en.wikipedia.org/wiki/Server_Name_Indication

Can you confirm mikrotik with this information? Can we disable DNS resolution and use SNI?

The problem is that the SNI name comes after the TCP connection is stablished.

OK but on firsts bytes. On first push packet

Enviado de meu SM-G800H usando Tapatalk