Most performant way to segragate device from home network

RouterOS Beginner Basics
1

Hello,
I’m new to the mikrotik ecosystem and I’ve my first mikrotik device on the way (mikrotik hex, RB750Gr3).
I’d like to find out what is the most optimal way to solve the following problem while keeping the performance as close to gigabit as possible:

  1. I have an ISP router and several Ubiquiti switches already in the network
  2. I’d like to add a device to the network that I’d like to isolate from the rest of the network while giving it access to the Internet (and there is a certain range of ports I’d like to forward to the device)

By isolating I mean:

  1. it can’t access any other device that is connected to the ISP router (other than the switches it needs to get there of course)
  2. it can’t access ISP router admin console/UI or mikrotik admin console/UI

Thanks

2

If the untrustworthy device in question is wired:


  1. Set this device’s proximate switch port to tag the traffic with a VLAN not equal to 1. Call it “666” for the sake of argument, this being a potentially “evil” device.
  2. Put all other switch ports onto a different VLAN — also ≠ 1 — so that these ports can all talk to each other, but not to the first VLAN since you haven’t gone out of your way to set up inter-VLAN routing. Let’s call it VLAN 127, being the “local” LAN. This takes care of the LAN part of the problem.
  3. Between switches, set up VLAN trunking so the 802.1q tags are preserved through the chain.
  4. At the hEX, set up bridge VLAN filtering, then set the routing rules so that VLAN 127 tagged traffic can go out the WAN interface only. The rest is allowed to hit the gateway’s bridge and go back inside the LAN, if that’s the best path. (Ideally, the switches keep LAN traffic entirely off the gateway router, but sometimes needs must…)

If the problematic device is wireless — as a great many untrustworthy IoT type things are — things get more complicated because now you’ve got a shared medium to partition. If your WiFi gear is smart enough, you may be able to set up a separate SSID for the problem devices which applies a VLAN tag, putting you back into the same logic chain above. If not, you’ll likely have to rely on specific features of the WiFi router in question to partition the traffic.

Perhaps the simplest option given stupid WiFi equipment is to dedicate one to “IoT” type things and connect it to one of the hEX ports, then jump into the VLAN chain above.

3

Hello, thanks for detailed reply.
I can set vlan routing all the way to the ISP router but it doesn’t have any vlan support so any traffic coming from the ISP router would be untaggable on switch level. Unless I put the hex between my whole network and the ISP router. Since the cabinet is quite filled already I was thinking about putting the hex next to the device.
And the device in question is not IOT and is wired.

4

The key idea in my plan is that you put the ISP router into bridge mode, then use the hEX as your Internet gateway router.

If the hEX instead must be way out at the edge of your network, then the only way I can think of to achieve what you want without any other changes is to use it to create a VPN gateway out into the public cloud somewhere, then force wired traffic from the “trouble” port through that VPN. There are several options to choose from in RouterOS.

Dedicate at least one port to an uplink to the rest of the LAN, for management if nothing else.

Your 1Gbps requirement means the endpoint will likely need to be a paid VPN service of some kind, else it will be the bottleneck.

5

Concur, if you cannot put ISP router into bridge mode, can you port forward ports to the hex, aka ALL the ports for example.

6

Ok, finally got the device today.
I don’t want to make the mikrotik the main router of the subnet nor do I want to impact in any way subnet under the ISP router. I’d like for mikrotik to act as a firewall.
My original idea was to add a firewall rule to drop all traffic to ISP router IP range other than the router itself and this works.
Now I’d like to allow device from the router subnet to manage the mikrotik and disable all devices on mikrotik bridge from managing it. I was able to disable local devices on bridge but I’m having a hard time right now figuring out how I can enable access for devices in the other subnet (over wan port).

7

If you already had a plan and didn’t intend to deviate from it, why did you ask for advice? Did you want us to guess your preconceived plan and then validate it uncritically?


add a firewall rule to drop all traffic to ISP router IP range other than the router itself

You asked for the “most performant” method, and then instead of accepting that advice, you went and found the least performant method and did it that way instead. The initial option I gave you took this restriction into account. Switch chip VLAN filtering offloads all decisions to the hardware IC doing the switching, while yours forces all traffic through the CPU so it can be seen by the Linux IP firewall. If you haven’t bottle-necked yourself to less than a gigabit already, continuing down this path will, sooner or later.

There are RouterOS based devices with switch chip rule tables which let it do firewall-like things in hardware, but the hEX isn’t one of these. Note the “no” in the rule table size column for the MT7621 switch chip — the one used in the hEX router — at the top of that page.

Note also that firewalling by IP is only as secure as the source of those IPs. You haven’t shown your configuration, but I would guess that all one has to do to get around your current scheme is assign a different IP to this segregated device. Given its segregated position, you might not even have to play ARP games to avoid potential IP conflicts.

My solution — port-based VLANs — does not have this problem.


allow device from the router subnet to manage the mikrotik

The performant way is to tell the enabled management services to listen for connections from allowed IPs:


/ip/service/set ssh address=192.168.1.0/26

The odd subnet mask restricts this to 192.168.1.1 - 192.168.1.63 under the assumption that low-IP’d devices are the management PCs and other “server” type systems on the secure side of the network, with static IPs, and that all the insecure devices use DHCP-assigned addresses from the upper end of the subnet range. But as above, this is secure only insofar as the segregated device is restricted from glomming onto .42 or whatever.

Alas, there is no negating this rule; you can’t say “!192.16.1.99/32” to make it ignore that one IP.

An alternative method that is more consistent with your current design and has the side benefit of avoiding the problem of IP-based security is to put that interface into an interface list and then add a firewall rule that matches on that list. The downside is that you still have the performance problem, because it adds an all-but-unskippable firewall rule since it has to filter out all attempts to contact the restricted services. The prior option puts less of a load on the CPU because it affects only incoming connections to the service(s) in question.

8

If you already had a plan and didn’t intend to deviate from it, why did you ask for advice? Did you want us to guess your preconceived plan and then validate it uncritically?

That was not my intention. I did not want to overburden the original post with too much details but it’s clear now that this was the most important detail - I’d like to avoid bridging the ISP router for several reasons:

  1. I hope to upgrade my ISP connection and router to multi gig this year - if I bridge ISP router now I’ll be forced to upgrade mikrotik as well.
  2. I have a main cabinet that is already crowded more than to my liking and I’d like to avoid continuing to do so.
  3. This cabinet is the central point leading to other floors in the house.
    Hopefully this clears it a bit, sorry for misguiding the discussion.

You asked for the “most performant” method, and then instead of accepting that advice, you went and found the least performant method and did it that way instead. The initial option I gave you took this restriction into account. Switch chip VLAN filtering offloads all decisions to the hardware IC doing the switching, while yours forces all traffic through the CPU so it can be seen by the Linux IP firewall. If you haven’t bottle-necked yourself to less than a gigabit already, continuing down this path will, sooner or later.

There are RouterOS based devices with switch chip rule tables which let it do firewall-like things in hardware, but the hEX isn’t one of these. Note the “no” in the rule table size column for the MT7621 switch chip — the one used in the hEX router — at the top of that page.

I understand and thank you for the detailed response. Is vlan route possible without putting a managed router in front of the ISP router?

Note also that firewalling by IP is only as secure as the source of those IPs. You haven’t shown your configuration, but I would guess that all one has to do to get around your current scheme is assign a different IP to this segregated device. Given its segregated position, you might not even have to play ARP games to avoid potential IP conflicts.

Vlan is ideal if possible given my situation.
Otherwise I’d gone the whitelist approach based on IP and mac address while also creating a strong password on the hex.

9

I don’t think so, because along with VLANs come multiple IP subnets, which then means you need a router capable of making decisions on those multiple subnets where they converge.

I expect these unspecified “Ubiquiti switches” of yours are all VLAN-aware, but presumably the ISP router is not, which means you’ll get one of two bad outcomes:


  • only one subnet is considered valid and the other gets dropped
  • it allows multiple subnets without understanding how to segregate them, resulting in commingled IP traffic, thus permitting hairpinning from the insecure side of the network back into the secure side

Ultimately, your problem comes down to a desire to make decisions at the edge that affect the entire network because you don’t want to change the core. Do you not see the inherent conflict here?

This is the virtue of my VPN alternative: it ships the problem traffic outside the LAN before it emerges in public, preventing it from hairpinning back in to affect the LAN by virtue of the ISP router’s NAT firewall.

10

I expect these unspecified “Ubiquiti switches” of yours are all VLAN-aware, but presumably the ISP router is not, which means you’ll get one of two bad outcomes:

only one subnet is considered valid and the other gets dropped
it allows multiple subnets without understanding how to segregate them, resulting in commingled IP traffic, thus permitting hairpinning from the insecure side of the network back into the secure side

Yes they are, I can vlan tag traffic on their ports but that’s about it. Multiple connections to the ISP router are useless because ports are all in bridge mode resulting in the bad outcomes you listed. I tried asking ISP support for possible options but no luck.

So if my understanding is correct my options are:

  1. put the hex in front of the ISP router and get most out of it, sacrifice the “cheap” path to upgrading the network - instead of just upgrading switches I’ll have to upgrade hex as well
  2. outsource the problem with paid VPN
  3. sacrifice the performance of the hex and it’s subnet to keep the upgradeability of the network modular
11

Regarding point 3, it’s possible to get a solid gigabit of traffic thru a hEX class device, but the more firewall rules you add, the less likely that becomes. The official test results show ~2 Gbps with significant firewalling, but this is an all-port test (i.e. 5-way traffic, not point-to-point) with max-sized packets. Real-world results vary. Test accordingly.

12

Hex vers7 <400 Mbps vers6 <800 Mbps real world.

13

Ok, thank you all for your help.