Pewnie w openvpn miałeś dodane dodatkowe trasy do podsieci a tu tego nie robisz. Tak?

Jeżeli gui czegoś nie przewiduje i ci nie działa to nie zrobisz z gui, bo proste...

Masz jeszcze konfigurację tego OpenVPN?

Od strony klienta Wireguard wygląda to tak:

Kernel IP routing table
Destination     Gateway         Genmask               Flags     Metric Ref    Use Iface
default            10.64.64.64       0.0.0.0                   UG     0      0        0 3g-wan
10.64.64.64     *                      255.255.255.255    UH     0      0        0 3g-wan
81.abc.de.255   10.64.64.64     255.255.255.255    UGH  0      0        0 3g-wan
192.168.1.0     *                      255.255.255.0        U      0      0        0 wg0           to chyba za mało, aby połączyć
192.168.2.0     *                      255.255.255.0        U      0      0        0 br-lan

Przy konfiguracji całego ruchu przez tunel, trasa 'default' jest przez 'wg0' i wtedy działa, ale to jest jasne, lecz bez serwera wtedy nie ma niczego.

Znalazłem kilka przyczyn braku działania połączenia od strony sieci lokalnej serwera do klienta przy włączonym jedynie tunelowaniu transmisji lokalnej.

1. Jest błąd w GUI Gargoyle PL, bo przy Zapisie zmian (nawet bez naniesionych zmian) konfiguracji klienta na kliencie w pliku Network jest zapisywane/nadpisywane:
        list allowed_ips '192.168.1.0/24'
zamiast:    
        list allowed_ips '192.168.1.0/24'
        list allowed_ips '10.64.0.1/32'

Ten drugi zapis (stworzenie trasy) powoduje, że da się łączyć od strony serwera do klienta po obu adresach 192.168.2.1 oraz 10.64.0.2 (przy jednym wpisie nawet łączenie na 192.168.2.1 nie działa).

2. Klient Wireguard nie odświeża adresu IP serwera z DDNS i transmisja na stałe ustaje po zmianie IP serwera (OpenVPN odświeża/pobiera co jakiś czas IP z DDNS i sam przywraca komunikację).

3. Podobnie, serwer Wireguard, jeśli trzyma połącznie ze starym adresem IP klienta Wireguard, to już nie da się przywrócić transmisji po zmianie adresu IP klienta.

4. Aby zapoczątkować/wystartować w ogóle możliwość połączenia od strony sieci lokalnej serwera do klienta niezbędne jest np. połączenie się z Androida z podglądem kamery (podsieć klienta Wireguard) za pomocą połączenia przez serwer kamery. Wtedy dopiero inicjuje się połączenie i transmisja działa w obie strony.

Czemu klient Wireguard sam nie rozpoczyna/inicjuje transmisji? Bez tego, nie może nastąpić żadna transmisja z zewnątrz.
Czytałem, że to może być cecha protokołu Wireguard, ale w taki sposób ten protokół nie nadaje się do takich typowych celów, jak mój.

Z tego co czytałem, to Wireguard to protokół bezpołączeniowy, czyli tworzy tunel tylko na czas transmisji.

Transmisję zawsze rozpoczyna klient, więc jeśli klient niczego pierwszy nie prześle (pakietu danych, a nie pakietu organizacyjnego), to serwer niczego do klienta nie może przesłać (brak tunelu).
To tłumaczy, czemu po restarcie nie mogę się połączyć z serwera do klienta.

To tym, jak połączę się do podglądu kamery przez protokół p2p producenta kamery (koniecznie od strony sieci lokalną serwera), to już komunikacja dwukierunkowa działa, bo kamera jest on-line poprzez internet klienta (nie tunel), ale po wysłaniu żądania przesłania obrazu, przesyła dane do sieci lokalnej, bo tam jest bliżej do programu Android do kamery) i tym samym sam klient zapoczątkowuje transmisję poprzez tunel (tworzy go).

Czemu inni nie mają takich problemów z Wireguard'em?
Bo używają zazwyczaj całej transmisji przez tunel (allowed_ips '0.0.0.0/0'), a przy pełnej transmisji zawsze coś jest do przesłania do serwera i tak się inicjuje transmisja i działa już praktycznie od restartu.

Zapewne Wireguard powstał, aby łączyć klientów z serwerem i to działa, bo sam klient rozpoczyna komunikację. A jak kończy przesyłać, to teoretycznie tunel ginie, co zapewnia większe bezpieczeństwo.

Tym różni się od OpenVPN, który tworzy tunel i jest on utrzymywany cały czas (i transmisja dwukierunkowa działa zawsze pomimo selektywnego tunelu), więc raczej OpenVPN nie zostanie wyparty przez Wireguard, bo służy do trochę innych celów.

PS.: Oczywiście można utworzyć zadanie i wykonywać co jakiś czas transmisję z klienta do serwera (co otworzy kanał), ale to jedynie obejście.

Napisałeś "Klient nawiązuje połączenie", czyli jest jak napisałem.
A czemu klient z kamerą ma rozpocząć transmisję, jeśli nie ma niczego do przesłania (do sieci lokalnej)?

Ja chcę jedynie się połączyć z kamerą przez jej panel WWW od strony sieci lokalnej serwera i to jest niemożliwe (bez inicjacji transmisji przez samego klienta).

No właśnie zrobiłem opisywany przypadek i jest tak jak opisałem.
Keepalive utrzymuje tunel przez dany czas i go zwalnia i znowu KLIENT MUSI rozpocząć transmisję, aby tunel się utworzył.

Jeśli jest inaczej, to podpowiedź mi jak zrobić działającą konfigurację, aby bez inicjacji tunelu przez samego klienta, można było się połączyć od strony serwera?
Jakiego parametru użyć, aby klient sam rozpoczął transmisję po restarcie i ją utrzymywał?

To co ustawić, aby klient zestawił połączenie, bo po restarcie serwera i klienta (LTE), żadne połączenie nie jest zestawiane?

Piszę oczywiście o tunelu jedynie dla transmisji lokalnej, gdzie Gargoyle przy konfiguracji ustawia: list allowed_ips '192.168.1.0/24'.

No ale w przykładzie jest tunel na całość ruchu, a tego nie chcę:

# uci add_list network.@wireguard_wg0[-1].allowed_ips="0.0.0.0/0"

PS.: Sprawdziłem i tunel nie jest utrzymywany (co jest sensowne, bo Keepalive=25), bo pomimo tego, że serwer (błędnie?) pokazuje połączenie Wireguard (od kilku godzin), to połączyć się nie da (od strony serwera). Uruchomienie podglądu kamery, czyli ponowienie transmisji od strony klienta (obejściem), przywraca łączność dwukierunkową.

Oczywiście, gdy ustawię: AllowedIPs = 0.0.0.0/0 , to nie ma żadnego problemu.
Jestem przekonany, że w pliku Network na klientach masz AllowedIPs = 0.0.0.0/0.

PS.: No chyba, że piszesz o OpenWrt, gdzie może nie ma błędów występujących w Gargoyle.

Nie jest możliwe utrzymywanie tunelu, bo przecież sam pisałeś, że jest ustawione Keepalive, a po tym czasie tunel jest zamykany.
Musisz mieć coś niewielkiego, co z klienta cały czas wysyła do serwera przez sieć lokalną i utrzymuje otwarty tunel lokalny.

Mój plik 'Network' z kleinta:

config interface 'wg0'
    option proto 'wireguard'
    option private_key ''
    option listen_port '51820'
    list addresses '10.64.0.2/32'

config wireguard_wg0 'wgserver'
    option public_key ''
    option route_allowed_ips '1'
    option endpoint_host 'zewnetrzny_adres_serwera_wireguard'
    option endpoint_port '51820'
    list allowed_ips '192.168.1.0/24'
    list allowed_ips '10.64.0.1/32'

No to może to jest rozwiązanie, bo nie mam Keepalive w konfiguracji?

Chociaż w tworzonym przez serwer Gargoyle pliku konfiguracji klienta jest 'PersistentKeepalive = 25', ale nie jest to najwidoczniej przenoszone do klienta przy imporcie.