The root element for anyone, who attempts to build vpn-based remote access, should be the fact, that native ESDR3-to-TX LAN round-trip UDP delay must be below/equal 30ms (ESDR2 is even less tolerant).
Note 1: UDP delay is not equal ICMP delay when we are talking about vpn (aka ICMP ping is mostly useless in that particular case).
Note 2: Any vpn-based access delay has to be calculated as the combination of the following: 'vpn encapsulation/deincapsulation delay' + 'vpn serialisation/queueing CPU delay' (this one is because any vpn traffic will go via CPU, unless you are using dedicated vpn concentrator, in which traffic flows via specific ASICs) + common WAN delay + UDP delay of each LAN segment.

The root element for in-build 'ESDR3 remote' feature - in context of current subject and opposite to vpn - is that there is webrtc-like mechanisms in place (and it is currently under active development, experiments and not finalised as yet). However, unlike vpn, there is no encapsulation/deincapsulation and CPU queueing delays + extra compensation mechanisms (to make it more tolerant to native WAN delays).

Если стоит задача построения удаленного доступа на основе vpn, то надо понимать, что мы пробрасываем через vpn траффик локальных сетей UDP (между ESDR и трансивером). Базой для расчетов является следующее:
- для ESDR3 предельное значение задерки UDP трафика в LAN должно быть не более 30мс (а ESDR2 и того меньше), и
- суммарная задержка для топологии должна расчитываться исходя из фактов, что
1. для абсолютного большинства случаев в WAN трафике, задержка UDP не равна задержке ICMP (то есть использовать ICMP ping для измерений бесполезно), и
2. При использовании vpn комбинированная задержка будет складываться из задержки vpn инкапсуляции + задержки очереди пакетов vpn, проходящих через CPU + типовых задерже WAN + непосредственно задержек каждого LAN сегмента. Увы, но тут для достижения нужного уровня в 30мс (для ESDR3) не хватит типового домашнего роутера, нужен нормальный vpn концентратор, в котором первые две задержки минимальны (в обмен на цену и сложность).

Именно поэтому - во избежание сложностей, и после подробного анализа - ЕЕ пошло по принципиально отличного от vpn пути и разрабатывает специальную фичу - встроенный в ESDR3 специализированный протокол удаленного доступа. Была речь (в свое время) про то, что он (возможно) будет основан на механизмах webrtc, но окончательно говорить пока рано, потому что как раз в настоящий момент ведется его активная разработка и тестирование в альфа-версиях и как будет выглядеть финальная реализация фичи, мы узнаем после всех тестов и изменений. Но то, что встроенный в ESDR3 удаленный доступ будет более стабильным, чем vpn, и более толерантным (за счет дополнительных механизмов компенсации) к обычным задержкам WAN - несомненно.

Надеюсь, после прочтения вышеизложенного полностью понятно, что все эксперименты с TP-link (и подобным), а также с энидесками и тимвьюерами - от лукавого. Ну только если из упрямства и желания впихнуть невпихуемое.

Мое личное предварительное мнение (на основе опыта) - и встроенный-то в ESDR3 удаленный доступ потребует оборудования получше, чем типовой домашний роутер. Но надо дождаться финальной версии фичи, тогда можно будет дать уже конкретные рекомендации для разных топологий.