Route v .OVPN souboru pro klienta mi připadá správně.
Ručně přidaný statický route v routeru je blbě, bude duplicitní a mohl by dělat neplechu - správně Jenda říká, že znamená de facto smyčku. Těžko říct, jak si firmware routeru přebere, že má cosi routovat na své vlastní lokální rozhraní - mně to smysl nedává :-) Cílem routu má být vždycky nějaká sousední mašina (IP adresa), na kterou "tento router" přímo vidí přes L2 médium. Počítám, že na routeru nemáte přístup do shellu - ale zkuste pohledat, jestli by někde ve webovém rozhraní nešla vypsat aktuální routovací tabulka z kernelu. Měly by tam být od přírody/automaticky subnety, kterými máte očíslovaná rozhraní. Tzn. ten 192.168.1.0/24 by tam už měl být, netřeba ho přidávat, router o něm ví. Ten subnet je totiž tzv. "directly connected", tzn odpovídající route není třeba předávat další gatewayi, provoz jemu určený se prostě odešle příslušným rozhraním (jenom se ARPem překládají IP adresy na MAC adresy přímo viditelné na L2).
Ping je jedna věc.
Na routeru si bohužel tcpdump zřejmě nepustíte.
Ale mohl byste z klienta zkusit poslat traceroute - pod Windows tracert.
Mimochodem, co máte na klientu za operační systém? Většina OS má v příkazovém řádku příkaz "route", kterým lze přinejmenším ověřit, jestli se po připojení tunelu objeví route specifikovaný v .OVPN souboru.
Pokud se provoz nerozjede ani po odstranění toho chybně přidaného routovacího záznamu na routeru, stálo by za prověření, jestli do toho nekecá firewall na "počítači v LAN", ke kterému se snažíte vzdáleně dobouchat. Tady by pomohl wireshark na dotyčném počítači v LAN, protože ten má odposlechovou sondu před firewallem (co nejblíž fyzickému rozhraní).
A pak je ještě možné, že forwarding z toho tunelu není automaticky povolen ve firewallových pravidlech na routeru... (jak psal Jenda. Že by na routeru byl paušálně vypnutý /proc/sys/net/ipv4/ip_forward, tomu z principu nevěřím.) Mít přístup do shellu, navrhl bych tcpdump, iptables -L apod. Leč, firmware je zapečený proprietární... Zlaté OpenWRT.