In the same physical LAN. Both are connecting to the same switch with WAN network, and the other same switch with LAN network where the client connect.
Hotspot: WAN 200.36.126.4/26 Gateway 200.36.126.1
LAN 10.10.1.254/24 DHCP server 10.10.1.1-10.10.1.249
Router: WAN 200.36.126.12/26 Gateway 200.36.126.1
LAN 192.168.1.251/24 No DHCP Server
The client 192.168.1.88/24 connect to Internet via Router without Hotspot turned on. Once Hotspot turned on, the client is redirect to the hotspot login page and no internet access until login to hotspot.
Question 1, Why the client redirect to hotspot which has a different subnet 192.168.1.x with 10.10.1.x ?
Question 2, Why the Bridge IP Firewall is passing the hotspot from LAN to WAN, how can I filter the hotspot ?
Is there any reason why you want to run these two services on the same interface? It might be possible to do, but why would you? It is very very easy then for an end user to bypass the hotspot and get online, and therefore completely defeats the purpose for the hotspot in the first place.
The hotspot is designed to internally NAT connections from end users with wrong IP address settings just so they can get online and get presented the login page. This is why your users that are on a different subnet get presented with the login page. You can try this rule, it should work. But as I said, all it will take is a user changing their IP address to the right subnet to bypass the hotspot, which is very easy to figure out and to do.
A much much better solution would be for you to run the hotspot on one interface and the other services on a different interface. Then to keep them separated on the switches/devices with VLANs or different hardware. Otherwise you are just asking for problems.
All clients are located in the same subnet of a WiFi cloud.
Some clients are known customer with fixed ip 192.168.1.x/24 and MAC filter by Router, only registered MAC can use the Router to get internet.
Some clients are known customer with Internet ip 200.36.126.x/26 and MAC filter by Bridge IP firewall, only registered MAC can passthrough the Bridge to get internet.
For all other unknown client will serve by Hotspot.
Problem: How can I configure the Hotspot not to reply 200.36.126.0/26, is the following correct ?
/ip firewall nat chain=pre-hotspot src-address=200.36.126.0/26 action=accept
That will be as close as you can get, but I’m not sure if it will work or if it will work reliably because of the way the hotspot works with universal NAT. I’m thinking what your goals are and the hotspot are fundamentally incompatible. You can give it a shot and see what happens, but I have a feeling you are going to have to look into a better way than that setup to get where you want to be.
Have you also thought about having the known customers have a different timeout period than the free ones, so that they only have to sign in maybe once a month? You could also look into providing paid users with their own SSID and encryption, that will bypass the hotspot altogether, and then have an open system for everyone else potentially. You can also try running PPPoE and Hotspot at the same time, but this is not supported by MikroTik at all, so if you get it to work, don’t expect it to always work. What it comes down to is this, you need some way to separate users that have paid for their service and users that have not paid for their service and having them all on the same logical interface like you are is not the way to do this.
Also, you can get the hotspot to not nat (I think you just leave its address pool set to none, but there may be more to it), and add the ip addresses (or ranges) you don’t want hotspotted to its bypass list. The hotspot will try to grab all IP traffic (pppoe is not IP as far as the hotspot is concerned), so you have to set up bypass lists.
I happen to know of a situation where it was necessary to setup an interface with all three of these (hotspot, pppoe, and not-hotspotted users, and there is a vlan involved in there as well now). Yes, its not the ideal (cough), but due to legacy issues, and limited equipment capabilities in portions of the last-mile (kilometer), it had to be set up this way, and just hope that the hotspot users don’t discover the bypassed IPs (which in practice they don’t; they could probably be firewalled to prevent it, but we haven’t gone that far yet as it doesn’t seem to be a problem). Eventually, hopefully this http://en.wikipedia.org/wiki/Rube_Goldberg contraption can be gotten away from in the case I am referring to, but it is possible.
One reason that I like RouterOS is that convoluted stuff like this is actually possible when necessary (emphasize “necessary”), not that one should be shooting for it as an ideal.
This is not the new way I am doing this, actually since 2 years ago I deployed it. JUST one difference is that I was using a old hotspot called FirstSpot and it worked fine. The old hotspot have DHCP server service providing for unknown client, it does not do Universal NAT but just its own subnet 10.10.1.x/24.
Can Mikrotik hotspot do the same way… just listen and reply to it own subnet 10.10.1.x/24 ?
leave the address pool in hotspot blank or none,
then you have to add two bypass entries (in ip bindings):
0.0.0.0-10.10.0.255 bypass
10.10.2.0-255.255.255.255 bypass
and a dhcp server, if you want to hand out dhcp to any clients that request dhcp.
You could actually probably finetune those bypass entries to only match whatever other subnets you put on the interface that you don’t want hotspotted. The above covers everything so you don’t have to worry about it unless you want to add things to the hotspot later.
