Akurat głupi AP nie zdejmuje wartości TTL z pakietów, które mogłoby wynosić "1" od dostawcy, a więc przykład w ogóle nie trafiony.

Ale wiesz, że jeżeli tradycyjnie podłączyłeś kabelek pod port WAN drugiego routera i nie zmieniłeś firewalla, to tak jednostronnie wyizolowana podsieć "2" może Ci trzepać hosty z podsieci openwrt1.
A hosty z openwrt1 nic nie mogą zrobić hostom z openwrt2 bo tamte są za WANem.
Chyba że tak chcesz....

Czyli dostawca nie ustawia TTL=1 żeby Ci gasły pakiety na openwrt2.
Jeżeli drugi router wychodzi na świat poprzez pierwszy router, na którym jest przecież maskarada, to nie ma możliwości żeby dostawca wiedział o podwójnym NAT.
A czy klienci openwrt2 mają TTL na domyślnych wartościach czy może oni wychodzą z małym TTL i pakiety nie dochodzą do konkretnych węzłów bo skończyły się możliwości hop-a (TTL=0).
Trochę może wymyślam, bo Ty się zarzekasz że sprawdzałeś kilka razy routery i masz dobrze w standardzie a więc wykluczam openwrt1 i openwrt2

Jasne, więc poprzez standardowe ustawienie, mam na myśli router openwrt zaraz po w graniu nowego firmware z drobnymi zmianami. Po kolei:
1. openwrt2 wpięty kabel w port wan sieci openwrt1 i tak @mar_w to w sumie jest izolacja tylko klientów2
2. adresacja openwrt2 zmieniona na 192.168.33.1 (openwrt1 ma 192.168.1.1)
3. póki co nie mam informacji jak to wygląda ze strony klientów openwrt2, ale jak napiszecie co sprawdzić to podjadę i wepnę się jako klient. Dodam, że wg klientów2 wcześniej działało. Jak chcecie mogę wrzucić pliki konfiguracyjne

Kabel wychodzący ze switcha LAN openwrt1 wchodzi do WAN openwrt2

[dostawca MM] --> WAN [openwrt1] LAN --> WAN [openwrt2] LAN --> klienci2
                                                              -> klienci1

Szkoda że nie widzę tego jaki klient2, no z tego co mam info nie działa

config network routera openwrt2 jest z drobnymi zmianami

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0'
        option proto 'static'
        option ipaddr '192.168.33.1'
        option netmask '255.255.255.0'
        option ipv6 '0'
        option delegate '0'

config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'
        option ipv6 '0'
        option type 'bridge'
        option peerdns '0'
        option dns '208.67.220.220 1.1.1.1'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 0'

Co mógłbym jeszcze sprawdzić od strony routera?

To są właśnie te drobne zmiany naniesione z poprzedniego działającego routera
Była to wersja LEDE, ale już nie pamiętam jaka, router się spalił

Obecnie też wgrałem LEDE, (żeby było możliwie najbliżej poprzedniego) VERSION="17.01.6, Reboot"

Wyłączyłem ten "Bridge" na wan, testuje...

To nie jedyny powód lede, sprzęt to stary tplink na 4mb więc nic specjalnie nowszego tam nie pójdzie

Jaki to model tego drugiego routera?

Dom : router https://i.imgur.com/IuB6Zwy.png | TP-LINK T1700G-28TQ |Zyxel XGS-1210-12 | 6x Ruckus r310 unleashed  + Ruckus icx7150-c12p | Truenas scale 124TB 25Gb| Xpenology 12TB | apc smart ups 750 lcd 100Mb/s - 25Gb/s
Podróżne : GL.Inet MT3000  +1TB hdd
Działka : rb260gs 1j wdm 1Gb+ ruckus r310 + nb m5 + kilka kamer ip  + panel 285Wp + lifepo4 12v 60Ah .

Póki co brak info z drugiej strony - a jak to zwykle bywa z klientami - jak brak info to działa
Czyli podejrzewam że mieszał ten wpis "Bridge" w conf network przy wlan
Dzięki za spostrzegawczość @Cezary

Zapomniałem dodać, ze na openwrt2 były dziwne wpisy traceroute jak poniżej:

openwrt2# traceroute google.com
traceroute to google.com (142.250.203.206), 30 hops max, 38 byte packets
 1  *
 2  *
 3  openwrt1 192.168.1.1

Czy ten Bridge mógł jakoś zaburzyć trasowanie?