On the "Mikrotik-Firewall" all Interfaces are in a Bridge…I want…Linux1 & Linux2 are not able to connect to each other.

These two choices are in conflict. The primary and original point of bridging is to create a single broadcast domain, where all hosts can see each other.

There are other purposes for bridging in RouterOS — e.g. bridge VLAN filtering — but you don't speak of these cases. Therefore, the simplest solution to this part of the problem is to take both ports off the bridge and treat them as the endpoints of two independent 2-station networks. Put a static "/ip address add" on each of these bare RouterOS interfaces, configure the Linux boxes for a compatible static address, and route the packets out to the rest of the network thereby.

If you need a bridge for some unstated reason, an alternative solution is port isolation, but I can't recommend it outright because it's available only in certain RouterOS switch models, and you don't say which MT products you're using. If you can use it, though, it operates at the switch chip level, making it more performant than your firewall rules.

You may still need a firewall rule with port isolation, though, because your 192.168.2.1 router gives a bounce path around it. If Linux1 tries to talk to Linux2, port isolation will force the packet upstream, but then the clever router says, "Oh, I know how to get a packet back to 192.168.1.0/24" and sends it right back. If your MT "bridge" router doesn't guard against this, port isolation goes for naught. To plug that hole, you need to add something like this:


With that addition, the hosts on the 192.168.1.0/24 side of the network are then fully isolated from each other. Best of all, this rule doesn't get invoked in the simple cases, handled by port isolation down at the switch chip level. It's a last-ditch backstop against sneaky people only.

i want to be sure that the request are coming from my "Mikrotik-Router".

That demands some type of client certificate/keypair. How you achieve it depends on the tunneling/crypto solution you choose:

• IPsec allows this via the documented eap-tls and remote-certificate settings.
• With WireGuard, the simplest way to achieve this is to create the tunnel directly between the host pairs, not from router to router. Then the only way to spoof the Windows box is to lose control of the private keys. (This solution is available in the IPsec case, too, but I think the UI for this is lacking in Windows compared to the WG GUI client's on/off checkbox. Plus, setting up something like strongSwan on the Linux side is a bear compared to setting up IPsec under RouterOS.) Add a firewall rule that drops all connections to the Linux boxes except WG's configured UDP port, and you force all comms through that WG tunnel.
• You don't speak of SSH directly, but "Linux" implies it. If you can limit your comms to SSH — which you often can due to OpenSSH's -D and -L/R options, or their equivalents under other SSH implementations — then you can restrict the server to key-based authentication. As with the WG solution, the only way to spoof the link then is to lose control of the SSH keys.

Port isolation works at the port level, as you should've been able to guess from the name, so no, a 9-port router isn't going to be able to isolate 100+ hosts. A cascade like this might work, though:



If you enable port isolation only on the CRS326-24Gs, the devices can talk amongst themselves via the CRS309, but if you enable it there, too, it should prevent that.

I switched your design to a CRS309 to get a bunch of fiber ports for cheap, letting us use 100% of the copper ports on the CRS326es for leaf devices. If you don't need the 10G backbone to extend down to these leaf device switches, the CRS310-1G-5S-4S+IN will do the same job for cheaper while still giving you a 10G backbone up to the core.

You'll want to switch to bridge packet filter rules instead of IP filter rules when using switches like this instead of a proper router like an RB5009, but I'm not seeing that as a fatal flaw in this plan. I might well be overlooking something, though. This is a "paper" design only, not a regurgitation of a working and tested physical installation somewhere.

This doesn't get you client identification by itself, but I refer you to the SSH/WG/IPsec client key ideas above. Do device-to-device connections instead of switch-to-switch or router-to-router, and now you have per-device authentication.

Replacing every switch was not planned.

Port isolation isn't a proprietary MikroTik technology. Your existing switches may support it.

as soon as i enable hardware offload on the Bridge-Ports the IP filter rules will not working anymore.

Yes, which is why I referred you to the bridge packet filter above. Its capabilities are not identical to the Linux kernel's IP filter, running on the CPU, but it's more efficient, and for many applications, they overlap sufficiently.

there are iot-devices in this network that are not able to create or join a vpn-tunnel

I did not overlook that, merely chose not to try designing around that restriction. The only identifiers a dumb IoT device presents (MACs and IPs) are spoofable, giving us no reliable way to do host identification. Any attempt to get by with what you've got gives you the same security as switching to "My Name Is…" party stickers for your corporate ID card standard.

The best you can do is keep them from interfering with one another and with the rest of the network. Shoving all non-WG traffic into a separate IPsec tunnel at the router level is a decent way to do that.

"Mikrotik-Firewall" ist not configured as the default gateway on the devices and i don´t know how to overcome this issue.

Do they not use DHCP? There's nothing wrong with running a local DHCP server to bring a bunch of foreign devices into line with a special IP scheme, as long as you're careful not to let that server be seen by hosts that need to go on using the site's existing DHCP setup.

It seems like the Bridge Filters also only work if Hardware Offload is turned off.

I expect that to depend on the switch model.

That table does remind us that there's also the option of switch chip rules. This is even lower-level, and some switch chips put a sharp limit on the number of active rules, but it might suffice.

All static IP-Addresses.

You might end up needing to play ugly srcnat games, then.