@trendy
i thought its that ISP router is not "required" for such a case, as all the packets are floating within openwrt router; i mean local clients trying to access local ip (via harpinning) ... maybe i am wrong?
in case hairpin doesnt work on ISP router... means it firmware issue, correct?
but for mine scenario isnt openwrt router enought?
thanks
Clients try to access the wan IP of the ISP router. Even if you create a rule to hairpin that IP on the OpenWrt, it will be rendered useless next time the IP changes, so it is not a permanent solution.
I suppose so.
thats where i thought it can be somehow done via iptables, that packets wont leave openwrt.
What ip changes? what ip are u reffering to?
thx
The wan IP of the ISP router.
well we can assume it Wont change ... as its fixed.
Very good, then run a tcpdump -i br-lan -vn tcp port 8123 to verify that it is working.
The openwrt in its default iptables configuration supports hairpin. Some ISP routers, e.g. Mikrotik does not support it from the default. I have an ISP Mikrotik router where I had to add hairpin rule to the underlying local network on top of the forwarding rule on the Mikrotik rouer. On the openwrt router I just did set up simple forwarding rule to the required service IP address. For the requests to the public IP ISP router coming from the local network, your ISP router requires a hairpin NAT rule in the very beginning of the firewall chain. Chain srcnat source address 192.168.xx.0/24 destination address 192.168.xx.0/24 action masquerade. This is how this rule looks like on Mikrotik routers. Your ISP router might have similar firewall. You will need to add this rule to NAT srcnat chain. Should be the second rule after srcnat for WAN. XX is your local subnet of the openwrt router.
OS on your ISP router needs to support the hairpin in its firewall. Look into your ISP router documentation.
IP address based connection forwarding or hairpin from ISP is then ruled out. You can still do domain based redirection based on dnsmasq.conf redirect the outgoing requests back to your local network. This can be done on the underlying openwrt router then.
In dnsmasq.conf add a line like:
address=/yourdomain.com/192.168.5.62
Change yourdomain.com to your actual domain and IP address 192.168.5.62 to the IP address serving the service.
The requests for yourdomain.com from your local network will land on the 192.168.5.62 IP address then.
hello,
thats what i practically did , issue is that android devices are not using local DNS server so it doesnt work on android devices 
Do the Android devices have another gateway / DNS server defined in their settings separately or is the wifi setting on the router feeding the Android devices wrong?
You can still intercept these DNS requests.
Only if DoH and DoT are blocked.
We've been down this road already, twice.
The solution that is coming to my mind is the DNS hijacking (for a simple rule or two rules) or a pihole like DNS server that is implementing complex schema on the DNS part.
I had a partial success blocking packets originating from the surveilance system by a simple iptables drop rule. It is a fact when the device does not find a first server, then it looks for a backup. I had to do it twice back then. I can imagine, that Android might have up to 10 built in adressess before it gives up.
@kukulo
I can try DNS hijacking, thanks.
whats the benefit of pihole?
yeah as u said ... 10 maybe or more 
But the one thing that's not clear to me is the fact:
when I remove DNS server 10.0.1.1 from the dumb router (where android is connected) everything works fine. Doesn't make sense to me at all.
thanks
I your case, none, since you can't get the DNS hijacking to work, and that's the 1st step.
Dumb router or dumb ap?
Dump AP doesn't touch the traffic flowing through it.
Apparently the 10.0.1.1 might be resolving your public ip for the domain that you are trying to resolve to your internal network. Get a rid of this DNS resolver.
i need to try.
sorry dumb AP,
but now i removed DNS 10.0.1.1 from dumb ap and it doesn't work... so no idea what happened...
i think its okay, bc on DNS server 10.0.1.1 i have that rule
address=/yourdomain.com/192.168.5.62