I don't think you can properly do what you are trying to with your current router (unless you can upgrade it to OpenWRT or equivalent.). Its also A LOT harder to do then you think - and probably can't be done through the web interface alone.
As has already been pointed out, each subnet needs to point to the router with an IP in its own netblock.
Thus on LAN Interface of the router you need to have 2 IP addresses - 192.168.0.1 and 192.168.0.254 (or, in the second case, an Ip address in 192.168.0.129 - 192.168.0.254 which you are not using). In order to do this you need to bind a second IP address to the router, and it does not appear to allow you to do this.
Even if you do achieve the above, you are still only part way to your goals.
If you are using DHCP, you need to have the DHCP server answer on both subnets, and provide IP's in the appropriate range for each subnet. Again, this is doable but probably not with your current router.
The question to ask though is "Why are you doing this". Doing this does not buy you any significant security/isolation because the systems are still on the same segment, ie computers in one half can read and respond to broadcast traffic in the other half. The typical way of handling this problem is thus a bit more complex - and again, you need more powerful router software to pull it off. (In order to fully understand what I'm going on about here, you need to understand the difference between a subnet and network segment - the 2 concepts go hand-in-hand, and generally 1 subnet=1 segment, but you are describing 2 subnets on 1 segment - which is often not what you want)
The way I have done something similar is thus -
I got a router which supported OpenWRT. I configured the LAN ports on the router into different VLANS. (Most 4 port routers are interesting in as much as the 4 lan ports are actually individually accessed, and the software makes them appear as a switch and interchangeable - but you can actually program them to be on different VLANS, and provide per-port isolation). You then put each VLAN in a different subnet, and assign an IP address to the router interface for each subnet. You will probably need 2 switches (if you have more then 3 devices in any subnet) - you would need to use 1 of the switches for each subnet. In this way computers are in different network segments and - from a practical POV - can't talk to each other without going through the router. [ That said, I can point you to articles which say don't rely on VLANS for security - although I don't agree with their conclusions ]
The full context of the setup is that we have 2 apartments with their own Internet connection and LAN which we have joined together using a RPi via jumper cabling in the garage. The whole point of this exercise was so that I can administer the upstairs apartment's NAS without having the network traffic leave the building (which would also make sharing data a LOT faster), and also retain each apt's Internet/network setup so that they may continue working in case the RPi goes down. Since the commodity routers in each apartment are so lacking in options and features, I was willing to compromise by manually adding routes to the hosts that I would do the administration from on my subnet.
It's true that I need to get a better understanding of networking, and I am continually in the process of doing so as an IT professional. I spoke with a colleague today about my issue and it turns out I didn't need to add any routes, I just needed to change the firewall rules to use SNAT instead of MASQUERADE and the subnets started talking to each other (I did also need to allow IPv4 forwarding as Paul suggested, thanks!):
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.0.0/24 -o eth0 -j SNAT --to-source 192.168.0.4
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.1.0/24 -o eth1 -j SNAT --to-source 192.168.1.4
Full iptables list:
# iptables -t nat -n -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * eth0 192.168.1.0/24 192.168.0.0/24 to:192.168.0.4
0 0 SNAT all -- * eth1 192.168.0.0/24 192.168.1.0/24 to:192.168.1.4
As you can see, now the traffic is staying inside the building when testing from host 192.168.0.3:
>tracert 192.168.1.1
Tracing route to 192.168.1.1 over a maximum of 30 hops
1 1 ms 1 ms <1 ms 192.168.0.4
2 1 ms 1 ms 1 ms 192.168.1.1
Trace complete.
Many thanks for your comments.
Best Answer
There's a bit of confusion here; that /32 doesn't refer to the size of any (sub)network, but to the range of addresses that particular routing table entry applies to. Usually the two are the same (because you route a network or subnet as a unit, right?), but macOS does things a little different for other hosts on the same local network. Let me add some lines before the ones you quoted:
Note that 192.168.1 (short for 192.168.1.0/24) is routed over en0 (aka link#4); not via any gateway, just over the interface itself. This is the network that the Mac itself is on. 192.168.1.1 and 192.168.1.125 are both specific addresses within that network range. If you compare those /32 entries with the 192.168.1 entry, they're basically redundant duplicates; they say the same thing, just about specific addresses instead of the entire network range.
I don't know why macOS creates these redundant address-specific entries, but it's probably related to another thing you can see in the listing above: macOS lists its ARP table entries in the routing table. The "openwrt.lan" entry above (which I'm pretty sure is actually 192.168.1.1, just listed by name rather than number) says that it's routed via en0 to the MAC address 46:94:fc:63:fc:7.
So what you're seeing in the route listing is a mix of actual network routes (like the "default" and 192.168.1 entries), and per-host entries (the /32 and MAC-targeted entries).