Don’t worry then. If you’re looking for long-term reliability then I would seriously consider something passive. One of the nice things about working with Mikrotik devices is that they are all configured in the same way, therefore if you have a correctly working configuration, it’s quite easy to adapt it to another device.
You’re off to a very good start. However it won’t work just yet. I’ll comment on the errors inline.
Although I understand what you want to do, the router won’t You have decided to use bridges for the ports to the PLCs. While this is certainly possible, I see no possible reason to do so. Anyhow, once a port becomes part of a bridge, it disappears as an IP interface (and cannot be assigned an address, routed to, become part of an interface list - this is accepted by the system, but it1s meaningless, etc.) So either use bridges, then use the bridge as the interface everywhere OR what I would suggest - just forego the use of bridges altogether.
Again, either use bridges everywhere and forget about the individual ports, or don’t use them at all.
The conntrack timeouts don’t have to be optimized in any way for your use case, however if you go ahead with setting them manually, setting udp timeout to 3m is not really recommended (I usually use 35s), however setting udp stream timeout to at least 6m is.
Your firewall filter rules are approximately ok. I wouldn’t allow input (this is the chain that handles input to the router itself) from the PLC side. Also the connection-state=new is redundant.
My recommendation would be to disable all your firewall filter rules while you configure and verify everything related to the policy routing stuff. After that is done, it is best practice to reinstate and refine you filtering rules, but I think it’s best to do things one thing at a time.
The other thing that you are missing is that the PLC devices actually have to be able to give replies to the packets that initiate packets towards them. How this is best done actually depends on the IP configuration on the PLCs. Your PLCs currently will see the incoming packets as coming from their real source address, and when they reply, they will attempt to send it there. If they have a default gateway configured then there, if they have none, it will get dropped.
A sure way to fix this is to rewrite the packets towards them as always coming from 192.168.0.180. This is done using srcnat rules, such as:
add chain=srcnat out-interface=ether2 action=src-nat to-addresses=192.168.0.180 comment=“PLC1 outbound”
(repeated for all PLC ports)
This can be done for all ports in one rule:
add chain=srcnat out-interface-list=PLC-PORTS action=src-nat to-addresses=192.168.0.180 comment=“PLC1 outbound”
You may see elsewhere action=masquerade with no to-addresses specified - this does the same thing.
Although the routing part of what you propose will work correctly as-is, I would suggest the following modifications:
add dst-address=192.168.0.2/32 gateway=plc1-bridge routing-mark=to-plc1 comment=“Route to PLC1”
to
add dst-address=192.168.0.0/24 gateway=plc1-bridge routing-mark=to-plc1 comment=“Route to PLC1”
Also, please pay attention to the fact that as your mangle rules are currently written, the “to-plc1” routing mark will be applies to packets coming from PLC1 (because the connection mark marks the connection, that is both direct and reply packets). For reply packets policy routing is not needed, therefore these mangle rules should be rewritten as:
add chain=prerouting connection-mark=plc1-conn action=mark-routing new-routing-mark=to-plc1 comment=“Route to PLC1”
to
add chain=prerouting in-interface=ether1 connection-mark=plc1-conn action=mark-routing new-routing-mark=to-plc1 comment=“Route to PLC1”
You have decided to use bridges for the ports to the PLCs. While this is certainly possible, I see no possible reason to do so. Anyhow, once a port becomes part of a bridge, it disappears as an IP interface (and cannot be assigned an address, routed to, become part of an interface list - this is accepted by the system, but it1s meaningless, etc.) So either use bridges, then use the bridge as the interface everywhere OR what I would suggest - just forego the use of bridges altogether.