Communications between two internal subnets

Hello,
I can’t seem to figure out how to get two subnets to communicate effectively. For example, suppose I have a RB750; ether2 is configured as 192.168.1.0/24 and ether5 is an independent port configured as 192.168.2.0/24. How do I allow these two subnets to communicate, and also, is it possible to “masquerade” the traffic between the two so that a device that has it’s own basic firewall and won’t accept traffic from a different subnet could see it merely as traffic in it’s own subnet?
Thanks.

Change the /24 to /22.. :wink:

You don’t need to change anything for traffic to flow between routed ports. It’s a router, it will route traffic, by definition. For a router there is absolutely zero difference between traffic flowing from LAN to WAN, WAN to LAN, or LAN1 to LAN2.
Of course you can NAT between LAN ports, again, there is no such concept for a router inherently. For NAT, just add source NAT rules with an action of masquerade and the appropriate out-interface, and probably src-address qualifiers. For the situation you were giving:

/ip firewall nat
add chain=srcnat action=masquerade out-interface=ether2 src-address=192.168.2.0/24
add chain=srcnat action=masquerade out-interface=ether5 src-address=192.168.1.0/24

You could be even more specific and only NAT when the destination address is that of the device that can only accept traffic from its local network. Of course order matters with NAT rules, so make sure they are in a sensible position of the ruleset.

If you need more specific help, post the output of “/ip address print detail”, “/ip route print detail”, “/interface print”, “/ip firewall export”, and an accurate network diagram.

Thank you fewi, the natting solution was exactly what I needed. One thing that baffles me though is why I would configure a source address vs. destination address in the rule. It seems backwards but it obviously works.

Src. Address is the address that the packet came from. When you change the src. address, the packet is still headed to the same location, and in the case of doing NAT on a LAN to a WAN, it now has an address that is publicly reachable, so the reply packets can get back to the router. Since the router uses connection tracking for NAT, it “remembers” what the original src. IP was for the connection and will change it back so it reaches the appropriate person.

Dst. Address is the address that the packet is going to. So by using this action, it changes address that something is going to, meaning it will end up at a different location than was originally requested.

Wow. I’m going to have to think that over a few times; it’s not clicking right away.