Isolated Guest WiFi Sans VLANs

RouterOS Useful user articles
1

One of several reasons I have yet to replace my non-MikroTik gateway router until this weekend despite being the biggest RouterOS fanboy evar — like, totally! — is that every guide I’ve seen on setting up guest/IoT WiFi thus far relies on VLANs, and that’s simply a non-starter here. Maybe one day I will finally be arm-twisted into taking on all that complexity, but that day is not today, for I have worked out how to get the effect I want without resorting to that heavy hammer.

I’ve written my configuration up here for your edification and critiques. I’m particularly interested to know if I’ve overlooked something in the firewall that lets especially sneaky people slip packets onto the private LAN.

2

It’s hard to tell if your setup is “water tight” because it very much depends on the rest of configuration of the wireless device itself and on overall topology of your network. You didn’t give that context in your article and that makes your article IMO pretty useless for a random reader.

And to give you a reason why VLANs are good in such setups: firewall configuration is central with VLANs.

3

I thought I made it clear in the article that we’re talking about a home Internet gateway. That puts it on the border between LAN and WAN, with the intent that traffic originating on wifi2g be able to go out to the Internet only, not between hosts on that guest net and not over to the private side of the LAN.

The rest of the wifi configuration is pretty much stock QuickSet AP Mode other than having the country, SSID, and PSK settings localized. The local IP scheme differs from the ones in the article, but not in important ways. I felt it was more important to conform to MT documentation norms than to give out my private LAN IP subnetting scheme.


And to give you a reason why VLANs are good in such setups: firewall configuration is central with VLANs.

Yes, so I have seen, resulting in the Swiss-cheese I spoke of at the top of the article. “Isolate everything!” “Except for this…and this…and this…but all without compromising security.”

If you have such a network, this is not the guide for you. My baseline purpose here is to replicate the “guest network” checkbox found in consumer-grade WiFi gateways. If I can better it without adding undue complexity, that’s great, but VLAN’ing everything is asking a lot to achieve this modest goal.

4

Well the separate bridge setup is well known, to split traffic at L2.

Just wonder why bother with that 2nd bridge, “the Guest bridge”. All could be done without that bridge, just directly on the wifi2g interface.
Maybe trying to do this while the bridge is already there, and wifi2g as a port on that bridge, the DHCP server setup would fail. But this is only because the wifi2g is a ‘slave’ interface to the bridge.
But maybe the new wifi interface has some limitation, The legacy WLAN virtual could do it.
If the bridge is really used for L2 connectivity (eg wifi to ethernet) then there is no need to have an IP address on any of those interfaces, and the DHCP server could be upstream the ethernet interface.

There is no need for any IP level connectivity for the MT itself, unless you do want it to play a L3 level role, like DHCP, NAT or masquerade.

I run a network with 60 AP’s, and none is doing DHCP, NAT, DNS or masquerade, and there are no VLAN at that AP level.
For remote maintenance they do have an IP address, but in a totally different IP range, and using different gateway.

At home I have a small 6 AP network, without VLAN, strongly separated, and only the 2 Internet facing routers do DHCP,DNS, SRCNAT, DST-NAT, masquerade, queue,

Your home network, and the guest network should not share a common ethernet uplink, for the 2 bridges.
Indeed VLAN or tunnel would split the traffic over one ethernet uplink connection.

5

I’ve skimmed through the article again and it’s still not clear to me that the article is about adding guest wifi on the main router device. I guess you put too much emphasis on how much you loathe VLANs :wink: and too little emphasis on the fact that it’s about “single network infrastructure device” network scenario with only QuickSet initial config applied.

In this case you nay want to stick to “interface list” concept of default firewall (i.e. use “out-interface-list=!WAN” instead of “out-interface=!ether1” in the last firewall rule) just to make your article useful for people who are not getting their internet over plain ethernet interface (e.g. PPPoE).

6

It kept yelling at me about slave this and slave that, so I gave up and did as you saw.

But, as ever when someone assures you the limitation isn’t hard-and-fast, it gave me the encouragement I needed to go try again. I’ve got it working here without the second bridge now, and I’ve updated the article to match.

Thank you! :man_bowing:


VLAN or tunnel would split the traffic over one ethernet uplink connection.

Yes, that is indeed a useful taking-off point for this article. Out of scope for it, but well worth mentioning at the end, yes, as it now does.

Thank you again!

7

It’s a few paragraphs in the “motivation” section. It answers the question, “but why don’t you do it with VLANs instead?” Now you know why.

Consider it a personality quirk, a matter of taste, if that helps you understand me.

If VLANs were easier to configure on RouterOS for simple cases like this, I might well have a different opinion.


it’s about “single network infrastructure device” network scenario with only QuickSet initial config applied.

I’ve clarified the intro to be clearer about this.

I considered going further and adding a diagram, but decided it would be too simple to carry its own weight. If a picture is supposed to counterbalance a thousand words on the pedagogical scales, “Connect this to that without connecting to all these other things” doesn’t justify it.


use “out-interface-list=!WAN”

Yes, good. Thank you.

8

Not even going to try… Its like, please tell me how to use my betamax player :stuck_out_tongue_winking_eye:
Without looking
BRIDGE no vlans for everything
guest WLAN port NOT on bridge
assign WLAN port IP address directly.

Article need not be any longer… :stuck_out_tongue_winking_eye:
I recently attended the mkx school of brevity. :slight_smile:

9

Personal remark: it was a bit hard to understand the password … :laughing:

On a serious note:
if you apply this to a device which acts as central router and AP together as you mention in the intro, I fully understand the approach.
I think even Quickset allows it (but most likely not on the AX devices, I’m sure it is there on legacy wireless APs).

If however your main router is another device, it can become rather complicated to achieve the same if you’re not using VLAN.
And for future expansion (adding APs), you’re more or less obliged to use it then anyhow.
My 0.02€.

10

Although I do realize you’re joking, I took it as a hint that the PSK example should be clearer that it is an example and not passphrase selection advice to be taken literally. It’s there because I don’t want the opposite misunderstanding to occur by implication: that the guest network should have no PSK at all.


I think even Quickset allows it

Why, so it does! I didn’t even think to try returning to QS, risking my other custom configuration being overwritten/erased.

I considered relying on my backups to try this out, but then I recalled that I’ve got a hAP ax lite on the shelf waiting for a job to do, so I pulled it down and applied that setting. I got this essential difference:


/interface wifi add … master-interface=wifi1 name=wifi2 …
/interface bridge filter add action=drop chain=forward in-interface=wifi2
/interface bridge filter add action=drop chain=forward out-interface=wifi2
/interface bridge port add bridge=bridge interface=wifi2

I was briefly confused by the use of bridge filters in the “forward” chain and IP filters, but what I think this says is that guest network hosts aren’t allowed to interact with anyone else on the bridge, but implicitly, IP traffic might be forwarded away via NAT. Is that correct?

Anyone care to weigh in on the pros and cons of these two approaches?

If this one does what I think it does, it’s probably more efficient, but I’m not certain it’s as secure. If nothing else, I find my configuration clearer, and one of the biggest enemies of security is an obscure configuration, leaving you unable to reason about it properly.


If however your main router is another device, it can become rather complicated to achieve the same if you’re not using VLAN.

I understand your point, but @bpwl’s idea about tunnels gets us past this obstacle, too. I’ve updated the article to mention this restriction and solution, so thank you for thinking of it. The article is now stronger for it.


And for future expansion

One AP covers my domicile adequately, and I have no plans for adding rooms.

If I did put in other APs to cover the corners better, the guest network would remain on the central AP only. I have no problem restricting guests wanting high bandwidth to the living room and IoT devices to the central AP’s range. Bandwidth does drop off at the edges, but with this router’s strong 802.11ax-1800 radios, it doesn’t drop below my Internet downlink speed until you get into the corners of the house. Even that isn’t a problem when we’re talking about things like smart power plugs, where even all the overhead of TCP/IP + TLS + HTTP + JSON can’t turn the device’s core changeable state — a one-bit on/off value — into more than a few kB per day.

11

Easy solution, buy any non-MT wifi router, they come with a built-in guest wifi. :slight_smile:

12

I use these bridge filter rules too. Some years ago I played around with quickset and compared config exports when changing anything in quickset. I liked the approach of using bridge filters for guest wifi - so I adopted it in my initial-provisioning script. Dead simple without the need for vlans.

13

I have not enough experience nor competence to appreciate or critique the contents of the article, but you deserve anyway a BRAVO! for the approach (unconventional).
I am slowly getting to the same conclusions you made about the possibility that overly complex approaches (and the modifications/exceptions added/needed to allow some specific functionalities) may lead to insecure setups.
Keeping things as simple as possibile seems like a good idea, particularly for the less experience users.
Keep up the good work with these articles, they are clear and a pleasure to read.

14

I hope it is okay to resurect this old thread.

I, too, have struggled with VLANS (and have been unsuccesful) and have wished for a non-VLAN way to create guest wifi networks.

I read your very well thought out and well written article here:

https://tangentsoft.com/mikrotik/wiki?name=Isolated%20Guest%20WiFi%20Sans%20VLANs

I was wondering if you had any updates, refinements, suggestions, or comments on this solution?

Thanks!

15

It’s still working here, as originally presented.

Were you hoping for some change, or just confirming the article’s published history, that nothing has changed in half a year?

16

I was not hoping for any specific changes. Just an assumption about ideas and implementation evolving over time.

What a fabulous system you have for tracking changes in the article!

Have you discovered any significant flaws, complications, or weaknesses in using this method?

If I understand correctly, the following code will set up SSID “Guest” that provides Internet-only access via wifi2g (a slave to wifi2):

/interface wifi configuration add name=guestcfg ssid="Guest" datapath.client-isolation=yes security.authentication-types=wpa2-psk .passphrase=yourGuestPSKgoesHere
/interface wifi add name=wifi2g configuration=guestcfg master-interface=wifi2
/ip address add address=192.168.99.1/24 interface=wifi2g
/ip pool add name=pool2 ranges=192.168.99.2-192.168.99.254
/ip dhcp-server add name=dhcp2 address-pool=pool2 interface=wifi2g
/ip dhcp-server network add address=192.168.99.0/24 dns-server=1.1.1.1 gateway=192.168.99.1
/ip firwewall address-list add address=192.168.99.2-192.168.99.254 list="Guest WiFi"
/ip firewall filter add action=drop chain=input dst-address=192.168.99.1 
/ip firewall filter add action=drop chain=forward dst-address=192.168.88.0/24 src-address-list="Guest WiFi"
/ip firewall filter add action=drop chain=forward out-interface-list=!WAN src-address=192.168.99.0/24

Adding 5ghz would require just adding the following (I hope):


/interface wifi add name=wifi5g configuration=guestcfg master-interface=wifi1
/ip address add address=192.168.99.1/24 interface=wifi5g
/ip dhcp-server add name=dhcp2 address-pool=pool2 interface=wifi5g

Thank you for this!