Subnet hosts on network table

[rustyshackleford]

Greetings. Since I made static routes to a couple of subnets, the pi-hole could finally show host IPs rather than the router's IPs. That was about a couple of days ago. Then I decided to install a development update on the Mikrotik Maps Lite router. The update broke it, so I had to make a reset. I had to make things all over again on that thing. Including the route to the subnet the pi-hole is on. Yet the pihole can't see the IPs on the subnets behind the Mikrotik router adress anymore since reset and setup. I can't find the other posts on subnets helpful, them having different circumstances as far as I could see. I'm sorry.
Pihole does show host IPs on the Fritzbox router subnet, which is before the subnet where the pi-hole is in.

Fritzbox (R1 192.168.0.1) pi-hole related route is: 192.168.1.0/24 gateway 192.168.0.2
Hosts visible in 192.168.0.0 255.255.255.248

The routing table of R2 192.168.1.0/24, where the pi-hole is:

#      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          192.168.0.1               1
 1 ADC  192.168.0.0/29     192.168.0.2     ether2                    0
 2 ADC  192.168.1.0/24     192.168.1.1     bridge                    0
 3 A S  192.168.100.0/24                   192.168.178.4             1
 4 A S  192.168.110.0/24                   192.168.178.4             1
 5 ADC  192.168.120.0/24   192.168.120.1   ether1                    0
 6 ADC  192.168.178.0/24   192.168.178.3   ether1                    0

Hosts are visible on this subnet.
The routes that are meant to lead to the subnets in question are the following:

#6 (R3, second Fritzbox), hosts visible
#3 (R4, Miktrotik Maps Lite, Access Point 1), hosts not visible
#4 (R4, Mikrotik Maps Lite, Access Point 2), hosts not visible
#1 (R1, first Fritzbox), as I said, hosts visible.

As I saw the table I've added a route that has 192.168.178.1 as gw for 192.168.178.0/24

The Routing table of 192.168.178.4 R4 (Mikrotik Maps Lite) with the access points where the hosts aren't visible:

 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          192.168.178.3                                1             
 1 ADS  0.0.0.0/0                          192.168.178.1             1
 2 A S  192.168.0.1/32                     192.168.178.3             1
 3 A S  192.168.1.0/24                     192.168.178.3             1
 4 ADC  192.168.100.0/24   192.168.100.1   bridge                    0
 5 ADC  192.168.110.0/24   192.168.110.1   MAGES.                    0
 6 A S  192.168.120.0/24                   ether1                    1
 7 ADC  192.168.150.0/24   192.168.150.1   Kowloon                   0
 8 ADC  192.168.178.0/24   192.168.178.4   ether1                    0

Route #0 has a routing mark from a mangle rule regarding 192.168.110.0/24 [AP 2] if you're wondering. I suspect no problem from that.
The routes that are meant to lead to the pi-hole's subnet (192.168.1.0/24 gw 192.168.178.3 [R2]) are is the following:

#3 R2

I've noticed the route 8 which just leads to ether 1. So I'll add a route that goes
192.168.178.0/24 gw 192.168.178.1

Since I made no change in R3 and hosts are visible from there, I'll leave its routes out of listing.

On the side note, the pihole is reachable over all the subnets. The pi-hole just can't see the IPs behind R4 like it did before the reset. I'm sorry to just bump this topic in here, but I'm just having no hope on finding anything helpful as I just coudn't find anything that matches.
I hope this topic is structured comprehensibly and useful. Thank you in advance.

[Bucking_Horn]

Your problem is not with Pi-hole, but rather with your network configuration.

You may therefore improve your chances for a knowledgable answer by also consulting other relevant forums specialising in networking.
It will be difficult even then. Providing a graphical overview of devices and networks may help your readers to understand your issue better (and maybe yourself as well ).

That said, no amount of routing will do you any good if your APs were NATing requests from associated clients beforehand. My first advice would be to check if you can configure your APs to this effect, and whether the latest updates you mentioned would've had possible impact on that.

[rustyshackleford]

Alright. I had solved it one way. As you said, NAT was the problem. I disabled for a test and also tested internet. Because no NAT used to mean no internet for some reason. But there it was, host visibility behind that router accomplished and internet access kept. I guess it's thanks to the routes I added, because my ISP objected to my-pihole when it was open to all origins and just didn't think of making a route with the R4's IP as gateway.

But then I remembered. I had NAT before the update and it was working. So I asked myself what I did differently then? I do need NAT if I want to accomplish load balancing, given it's possible with routes and or VLAN (it has only 1 ethernet port, because AP design).
So I split the NAT. One masquerade NAT rule for each bridge as output, instead of having one masquerade rule with WAN asa output. In openWRT and RouterOS it's some kind of carrier for a subnet and or VLAN (why VLAN needs a bridge, I don't know, cpu switching maybe). And it worked. I was having internet and pi-hole saw the hosts behind the access points. I especially tested it with putting the ip to the group with an extra blacklisted domain. No access to that domain. It's working. While I was testing around with NAT, I instantly got access to that domain with the wrong NAT settings.

So, bottomline: I discovered two solutions to this topic to choose from.

The solutions in detail:
Solution 1: Disable NAT. And take care about a route or two leading the pi to the subnet and maybe even both directions. Since it may depend on topologies and stuff, I can't give advice oh how.

Solution 2, which is necessary for load balancing (leaning on RouterOS, may or may not be similar to other routers with extensive firewall):
I went to IP>Firewall>NAT
clicked on add new.
On chain I chose srcnat.
On out. interface I chose the bridge.
For action I chose masquerade.
And then I clicked on apply.
I repeaded it this to add the bridge of the other AP for testing. It may not be necessary for both bridges. So most probably only the bridge to the subnet to be connected to two internet accesses needs that sort of NAT rule.
On the router's CLI, the command would be:

ip firewall nat add chain=srcnat out-interface=[bridge] action=masquerade<

May differ with other routers. Typing the question mark after add may give you help.