Hotspot VLANs

I have a question about hotspot module and user VLANing. We want to isolate customers in hotel rooms for security purposes. The image below shows what we need to do. On the Mikrotik we need:

  • One hotspot definition
  • Hotspot doing DHCP with one DHCP pool
  • Hotspot users to be VLANed off for security and isolation reasons
  • Each hotel room to have a different VLAN tag

I know it is possible if there is one hotspot defined for each VLAN (along with a separate dhcp server for each), but with hundreds of hotel rooms this is not practical. It would be a management nightmare. I have looked at the forums for many hours and have tried many different things, but I cannot get many VLANs on a single hotspot. Is this possible? Has anybody else done this? If so, how?

What Cisco switch platform? Most are able to apply access-lists to switched ports so you could just drop all inbound traffic (from the switch perspective, so everything the customer puts on the network) that goes to the local network, but isn’t aimed at the gateway. Recent platforms can do both ways, which would be preferrable, but even filtering one way only will be very effective.

We have several customers using different switching platforms. Some have Cisco switches and others don’t.

create bridge, add all vlans to bridge, use bridge interface for hotspot, dhcp, etc., block forwarding between bridge ports in firewall filter

Chupaka

Can you give us an example.
l also needed a solution for mine bridge

an example?..

/interface vlan
add arp=enabled comment="" disabled=no interface=ether1 mtu=1500 name=vlan1 use-service-tag=no vlan-id=1
add arp=enabled comment="" disabled=no interface=ether1 mtu=1500 name=vlan2 use-service-tag=no vlan-id=2

/interface bridge
add arp=enabled disabled=no

/interface bridge port
add bridge=bridge1 disabled=no interface=vlan1
add bridge=bridge1 disabled=no interface=vlan2

/interface bridge settings
set use-ip-firewall=yes

/ip firewall filter
add action=accept chain=forward disabled=no in-interface=ether1 out-interface=bridge1
add action=accept chain=forward disabled=no in-interface=bridge1 out-interface=ether1
add action=reject chain=forward disabled=no

I attempted this and I got strange results.

My Tik setup:
ether1 = internet connection
ether2 = plugged into an 802.1q trunk port of a Cisco switch
ether3 = unused for now

On my Cisco switch:
eth1 = 802.1q configured trunk port connected to ether2 of the Tik
eth9 = vlan109
eth10 = vlan110
eth11 = vlan111
eth12 = vlan112

With the VLANs on ether2, I put in a different but similar config and added VLANs to a bridge called subscriberBridge:

/interface vlan
add arp=enabled comment="" disabled=no interface=ether2 mtu=1500 name=vlan109 use-service-tag=no vlan-id=109
add arp=enabled comment="" disabled=no interface=ether2 mtu=1500 name=vlan110 use-service-tag=no vlan-id=110
add arp=enabled comment="" disabled=no interface=ether2 mtu=1500 name=vlan111 use-service-tag=no vlan-id=111
add arp=enabled comment="" disabled=no interface=ether2 mtu=1500 name=vlan112 use-service-tag=no vlan-id=112

/interface bridge port
add bridge=subscriberBridge disabled=no interface=vlan109
add bridge=subscriberBridge disabled=no interface=vlan110
add bridge=subscriberBridge disabled=no interface=vlan111
add bridge=subscriberBridge disabled=no interface=vlan112

/interface bridge settings
set use-ip-firewall=yes

/ip firewall filter
add action=accept chain=forward disabled=no in-interface=ether2 out-interface=subscriberBridge
add action=accept chain=forward disabled=no in-interface=subscriberBridge out-interface=ether2
add action=reject chain=forward disabled=no

I then plugged in a DHCP enabled device to eth9 on the cisco switch (which should show up as vlan109 in the tik.) When the device attempted DHCP, in torch I see ALL the VLANs showing up as requesting DHCP. The DHCP server doesn’t seem to acknowledge that it received a request because it doesn’t even show the DHCP lease was offered. Now, if I remove all the VLANs from the subscriberBridge except vlan109 the device works with vlan109. As soon as I add a new vlan interface to the subscriberBridge, vlan109 stops working and torch shows the same thing (multiple DHCP requests from ALL the VLANs.)
ScreenHunter_0036.jpg

on Torch, you see MikroTik Neighbour Discovery packets, not DHCP Discovery

Oh, I see. I’m still not getting DHCP on the device though. Tried a computer and that didn’t work either. I’m also not seeing DHCP requests coming across ether2 for any incoming VLANs. All I see are the Neighbour Discovery packets.

But when I take off all but one VLAN from the bridge, only the VLAN that was left on the bridge gets access to the DHCP and hotspot. I also start to see traffic from all the VLANs.
ScreenHunter_0038.jpg
ScreenHunter_0037.jpg
These screenshots show the attempts when a computer was connected to vlan110. Now I can see attempts from vlan109. But, if I add vlan109 back to the subscriberBridge, none of the vlans can DHCP.

have you tried disabling firewall filter rules? =) who know…

Disabled all filter rules. Disabled hotspot. Same result. :confused:

if you setup client’s address manually (not via DHCP), can you ping router’s address?..

Its possible, i would start from a fresh install.

Script to make vlans

:for i from 101 to 220 do={/interface vlan add interface=lan vlan-id=$i name=(“vlan” . $i) disabled=no}

/interface bridge add

Script to add ports to bridge1

:for i from 101 to 220 do={/interface bridge port add bridge=bridge1 interface=(“vlan” . $i) disabled=no}

I also use this rule to isolate the vlan clients from the soft-bridge. EDIT: This rule needs to be put in the bridge filter, and no filters in ip firewall at this point.

/interface bridge filter add chain=forward in-bridge=bridge1 out-bridge=bridge1 action=drop comment=“” disabled=no

Configure dns address and allow remote requests:

/ip dns set primary-dns=10.166.26.1 allow-remote-requests=yes

Enable IP Firewall for bridges:

/interface bridge settings set use-ip-firewall=yes use-ip-firewall-for-vlan=yes

And then setup

/setup

define bridge1 address of 192.168.2.1
define ether2 (wan) address of 10.166.26.50
gateway is 10.166.26.1
ether1 has no address, and is not part of the bridge.

At this point, you should be able to set up your hotspot, since you only want hotspot gateway.

good luck.

That seems to have worked! :smiley: Now to figure out why it wasn’t working before. Time to back up that configuration.

Thanks for all the input everyone!

So after backing up the config that worked and resetting to default, I think I found the trick. I’m not sure why, but this rule is what did the trick:

/interface bridge filter add chain=forward in-bridge=subscriberBridge out-bridge=subscriberBridge action=drop disabled=no

Without this rule, I got the weird results described previously, but when adding this rule things started behaving how we envisioned.

So, for the record I did:
Start w/ an empty bridge

/interface bridge add name=subscriberBridge

Configure bridge to firewall bridgeports and VLANs

/interface bridge settings set use-ip-firewall=yes use-ip-firewall-for-vlan=yes

Create VLAN(s)

/interface vlan add interface=ether2 vlan-id=101 name="rm201" disabled=no
/interface vlan add interface=ether2 vlan-id=102 name="rm202" disabled=no
/interface vlan add interface=ether2 vlan-id=103 name="rm203" disabled=no
/interface vlan add interface=ether2 vlan-id=104 name="rm204" disabled=no
/interface vlan add interface=ether2 vlan-id=105 name="rm205" disabled=no

Add ports to subscriberBridge

/interface bridge port add bridge=subscriberBridge interface="rm201" disabled=no
/interface bridge port add bridge=subscriberBridge interface="rm202" disabled=no
/interface bridge port add bridge=subscriberBridge interface="rm203" disabled=no
/interface bridge port add bridge=subscriberBridge interface="rm204" disabled=no
/interface bridge port add bridge=subscriberBridge interface="rm205" disabled=no

Set up magic bridge filter rule

/interface bridge filter add chain=forward in-bridge=subscriberBridge out-bridge=subscriberBridge action=drop disabled=no

Then, I set up IP address, firewall NAT, DHCP, hotspot, etc on subscriberBridge.

yes magic bridge filter is the vital piece to this setup. its very busy as you will see. :slight_smile:

/interface bridge settings set use-ip-firewall=yes use-ip-firewall-for-vlan=yes

This is slightly off your topic, but you are one of very few using the ip-firewall-for-vlan=yes command.

i would like to use the above to mark packets per vlan for QoS, can some one go into some detail as to the exact operation of this feature? Does this simply enable me to perform firewall operations on bridged vlan interfaces once enabled or wheth this will implicitly peek inside vlan tagged traffic on a bridged physical interface and perform firewall operations without explicitly having to name each vlan?

Hallo,

we run the same setup in our lab in the context of ipv6 preparation. works without problems. We run multiple DOCSIS 1.1 Setups which do not support IPv6 natively in a routing environment. There is a feature called “transparent lan services” on cisco ubr, which basically maps a docsis modem to a tagged vlan and would make it possible to support “ipv6 nd” over docsis 1.1 (l2-vpn).

Has there someone experiences about the scalability and performance of this solution in an isp environment? We run clusters from 100 to 1300 cablemodems, ergo 100 up to 1300 tagged vlan’s + bridge ports. I cannot test such a huge setup in a lab realistically and would have to do some tests out in the field. Perhaps there is someone out there sharing his experience before annoying some customers? :wink:

thanks
Oliver

Ok Guys,

first problem with this setup in a real environment with 100 tagged vlans. I just emailed this to support:

[…]

Now we discovered a weird problem. Some clients (especially Vista) send DHCP-Discovers with Broadcast-Flag set. The dhcp-server on the bridge interface answers them with an offer to 255.255.255.255 (ff:ff:ff:ff:ff:ff) which is the intended behaviour. But this offer is not spread over all of the vlans on the bridge interface which it should be as a broadcast domain. I put a sniffer on the outgoing ethernet interface and I have seen that it starts sending the offer on vlan 100 goes down each vlan but suddenly stops on vlan 20. It does not send the offer on vlan 20 down to vlan 2, which makes it not possible for dhcp clients on those vlans to receive the offer. These clients stuck in dhcp state “offered”.

When I limit the vlan interfaces attached to a bridge interface < 50 everything is fine. I consider this as a bug?! It’s probably a timing problem, cause frames to “255.255.255.255” have to be cloned to all vlan interfaces. Or it is just software limited to some value.

thanks!
Oliver

which ver are u using. had the similar issues on 4.17 and 5.7 with about 120 vlans.
the dhcp and hotspot server stop working with some of the vlans.