Giga SE (KN-2410) v.3.6.10 Проблема с PPTP подключением из linux (ubuntu 20.04) на роутер

[progmachine]

Привет всем!

Купил тут себе новенький Keenetic Giga SE, в замен устаревшему Keenetic III. Установил, всё настроил и всё вроде нормально работает. Кроме PPTP VPN подключения из линукса, как оказалось.

Перевёл шифрование MPPE в режим 128 бит, всё настроил. Винда нормально по PPTP подключается. А вот линукс... соединение устанавливает, tcpdump показывает достаточно интенсивный обмен PPTP, GREv1, и всё вроде бы хорошо, только данные не передаются, ни чего не пингуется.

Далее настроил, и кучу раз перенастраивал линуксовое PPTP соединение:

Раньше с прежним Keenetic III всё это работало без нареканий, как в Windows, так и в Linux, VPN соединение устанавливалось и работало как надо.

Теперь соединение в линуксе устанавливается, но передачи данных по нему нет. tcpdump выдаёт кучу повторяющихся подозрительных сообщений (особенно Prot-Reject, что бы это значило):

19:03:04.499803 IP clienthost_name > server_ip_addr: GREv1, call 31, seq 786, ack 755, length 92: compressed PPP data
19:03:04.499851 IP clienthost_name > server_ip_addr: GREv1, call 31, seq 787, length 99: compressed PPP data
19:03:04.499875 IP clienthost_name > server_ip_addr: GREv1, call 31, seq 788, length 101: compressed PPP data
19:03:04.499990 IP clienthost_name > server_ip_addr: GREv1, call 31, seq 789, length 90: compressed PPP data
19:03:04.500018 IP clienthost_name > server_ip_addr: GREv1, call 31, seq 790, length 90: compressed PPP data
19:03:04.500129 IP clienthost_name > server_ip_addr: GREv1, call 31, seq 791, length 101: compressed PPP data
19:03:04.501435 IP server_ip_addr > clienthost_name: GREv1, call 2226, seq 756, ack 790, length 24: LCP, Prot-Reject (0x08), id 65, length 8
19:03:04.501460 IP server_ip_addr > clienthost_name: GREv1, call 2226, seq 757, ack 791, length 24: LCP, Prot-Reject (0x08), id 66, length 8
19:03:04.501466 IP server_ip_addr > clienthost_name: GREv1, call 2226, seq 758, length 20: LCP, Prot-Reject (0x08), id 67, length 8
19:03:04.501471 IP server_ip_addr > clienthost_name: GREv1, call 2226, seq 759, length 20: LCP, Prot-Reject (0x08), id 68, length 8
19:03:04.501482 IP server_ip_addr > clienthost_name: GREv1, call 2226, seq 760, length 20: LCP, Prot-Reject (0x08), id 69, length 8
19:03:04.501487 IP server_ip_addr > clienthost_name: GREv1, call 2226, seq 761, length 20: LCP, Prot-Reject (0x08), id 70, length 8

Ну и то что в диагностическом логе на Keenetic-е:

[progmachine]

Начался рабочий день, и начались проблемы...

Ноутбук у сестры подключен к интернету через этот роутер, по проводу. Начался рабочий день, и она запустила VMware Horizon Client - всё, новенький кинетик ушёл в перманентный ребут. Отключил сестру от сети, кинетик ещё раза 3 ребутнулся и стабилизировался. Что этот VMware client может посылать по сети такое, что роутер ребутается?... Подумал, что может он устанавливает какой-то тунель, пакеты которого кинетик не может маршрутизировать нормально. Зашёл в компоненты, поставил ещё Шлюз прикладного уровня ESP, вроде это название протокола, по которому IPsec какие то данные передаёт. Но после этого кинетик опять ушёл в перманентный ребут, теперь даже и без VMware клиента.

Пришлось выдернуть новенький кинетик, и воткнуть обратно надёжного проверенного старичка Keenetic III.

Очень не хотелось бы возвращать новенький девайс по гарантии, всё таки как железка он классный, софт вот только подводит (((