When I Google, I get mixed results 
Can someone confirm that it is possible to do Private VLAN on the RB4011 router?
Yes it is very possible.
TO help you get there, draw a network diagram of what you would like to achieve.
and post your current config
/export hide-sensitive file=anynameyouwish
As @anav already wrote (using different words): what exactly does “Private VLAN” mean in your context? If wikipedia article describes your view of the matter, then … hell yes, RB4011 can run large number of private VLANs.
a vlan is semi-private to start with LOL
perhaps he is talking military ranks and he really wants a Captain VLAN.
Without the big 3, we can only play games.
- /export hide-sensitive file=anynameyouwish
- network diagram
- Set of detailed requirements (users/devices needs (allowed and not allowed) without any mention of config.
I would like everyone connecting to RB4011 to be isolated from each other and only connect to internet and a few other internal services.
Easy peasy and please read this article to get you going.
When you have a config to present of your best attempt, please come back and we can go from there…
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1
What do you mean ? Everyone isolated from everyone ? Even if they are on the same VLAN ?
Yes - only cloud services are used. So we want everyone to be in their own bubble.
That is fine, you will need to create a vlan for every person.
You will need to enable the use-ip-firewall feature in the Bridge settings or use-ip-firewall-for-vlan if you use VLANs so that you can filter Layer 2 traffic…
Isolating everyone from everyone is not something that will happen just because you createVLANs..
Also, you will need to adjust the firewall as well…
Or use bridge split horizon.
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 horizon=1 interface=ether1
add bridge=bridge1 horizon=1 interface=ether2
add bridge=bridge1 horizon=1 interface=ether3
add bridge=bridge1 horizon=1 interface=ether4
Ports ether1-ether4 are now isolated & cannot communicate with each other.
If more that one users exist on the same port, that would not work …
If more than one user exists on the same port, then nothing on MT device can prevent those users talk to each other as long as they are in same VLAN (or none VLAN).
Hence each user gets a vlan 
Doesnt hotspot authentication (and or user manager) separate users as well??
Any mechanism trying to separate users can work as long as the port (or pseudo port[*]), used by user, is dedicated one. As soon as multiple users share one port (even through a downstream switch which is not managed with goal to separate users, e.g. a dumb switch), there’s nothing device can do to keep them separate.
[*] wifi interface itself is kind of a switch because wifi clients can only talk to AP, they can not talk directly to each other. Which means that client separation works even for clients connected to same AP. And I think of every client registered to AP as a pseudo-port.
The concept of “each user gets a VLAN” can work if access point knows to deal with VLANs, which implies managed switch (or smart AP which can do MAC-based VLANs). This concept can’t be delegated to end devices though.
Why not if i enable the Bridge Firewall ?
You can successfully block users to reach each other using the Bridge Firewall even if they exist on the same interface…
Only if you somehow force both hosts to communicate through bridge, which is usually hard to achieve.
Basics of IP over ethernet networking:
- hostA with IP address A.B.C.d/24 tries to establish connection with hostB with IP address A.B.C.e/24 (any IP adress/mask pair will do as long as both IP addresses are inside same IP subnet and mask correctly covers both addreeses)
- consults IP routing table and notices that hostB is inside same IP subnet. This means traffic can be performed directly on L2 (ethernet). Thus starts ARP whohas procedure which includes ethernet frame sent to broadcast address.
- broadcast frame is received by
- all hosts connected to same collision domain (e.g. an ethernet hub) because that’s the way collision domain works
- all hosts connected to same ethernet domain because switches (and bridges) forward broadcast frames to all ports except ingress port
this bullet is true if switches are not specially configured to do some funky stuff
Note that ethernet switches and bridges in general don’t transmit a frame through ingress port (basic requirement to avoid loops in L2), neither unicast, broadcast nor multicast.
Bullet 3.a is not very common these days, vast majority of ethernet networks go with bullet 3.b. If hostA and hostB share same bridge port, this usually means there’s an ethernet switch between bridge port and both hosts.
There are a few special cases where two (or more) L2 hosts share common physical connection towards the rest of network but can not communicate directly in the manner described (e.g. HPE ProLiant servers with iLO when using combined network port for both iLO and LAN), the only way such devices can communicate with each other is via router. - hostB receives broadcast frame, notices hostA (identified by src MAC address) is asking about hostB’s MAC address. hostB replies with unicast ARP reply which gets delivered back to hostA
- hostA starts to send IP payload using hostB’s MAC address and hostB happily replies using hostA’s MAC address.
If trafic between hostA and hostB doesn’t have to pass specially configured bridge due to any reason, then frames will flow between hostA and hostB because specially configured bridge can not drop frames not passing it, can it?
The only way bridge can block traffic between clients connected to same bridge port is when clients (hostA and hostB) are not aware that they could communicate directly. Which mostly means that they are either in different IP subnets and thus have to use gateway to route traffic between both subnets … or both clients are actually configured (this way or another) to be in different VLANs (but in this case while they use same physical port, they are in different VLANs) … or either host (or both) are tricked to think the peer is behind completely different MAC address (e.g. bridge’s MAC address if bridge is configured with arp=proxy-arp on all ports, but even this is not huaranteed to “pull” traffic to bridge, success depends on how quick is bridge when relying to ARP whohas requests compared to real host … it seems that the faster one wins).
Wireless interface, configured with forwarding=no logically falls in the same category as mentioned as special cases in bullet #3 above … frames use same bridge “port” but wireless clients can not communicate with each other because bridge will not transmit frames back through ingress port (necessary to reach the other wireless client). Configuring wireless interface with forward=yes virtually adds a switch, in which case frames between wireless clients never enter bridge as they are sent out via radio.
@mkx, i have nothing to disagree with…
But, when using the Bridge Firewall, in order for it to work, you must disable the hardware offload, otherwise the traffic will bypass the CPU and the Bridge Firewall filter will not work…
So, since it works ( at least on a quick lab test i run ), i can only think that the traffic flows through the CPU even if both devices are on the same port, thats why it works…
At least that makes sense to me..
What is your opinion ?
As I wrote (more than once 
): for bridge to block traffic between two hosts traffic has to travel through bridge. If hosts are connected to different bridge ports (e.g. ether13 and ether42), then device is able to interfere, technicalities on how to achieve that are minor (yes, if using IP firewall for in-bridge traffic, it is necessary to force packets through CPU and disabling HW offload on (at least) one of those ports does the trick).
@mkx, my actual test was on a Wireless interface (i know it can be done with setting forwarding to no)… On a wireless interface it is obvious that more than 1 hosts can exist on that same interface… And ofcorse on the wireless interface all the traffic goes through the CPU… Thus i could effectively allow or drop traffic selectively between hosts using the Bridge Firewall…
I think we are saying the same thing… Yes, the only way two hosts to exist on the same physical port is if they are actually connected to a secondary switch and then to that specific port (and again technically they are not connected to the same port) … In that case ofcorse they can communicate without reaching that port… So yes you can’t block anything …
It makes sense only on different ports or on Wireless interfaces in case you want to selectively allow or drop traffic …