General • Re: Mikrotik Router as Firewall only, how to verify the source?

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.

Statistics: Posted by tangent — Sat Mar 16, 2024 11:04 pm

---