Все о туннелях IPIP, GRE и EoIP

[Le ecureuil]

11 минуту назад, toga сказал:

Доброго времени суток. подскажите можно ли подключить Keenetic Giga III к Zywall USG50 по IPIP или только EoIP

Можно подключить к Zywall USG50 по GRE или по GRE/IPsec, или же по L2TP/IPsec как клиента.

[toga]

В 13.01.2017 в 11:19, Le ecureuil сказал:

L2TP/IPsec как клиента

что - то не нашел ни каких внятных настроек, можно попросить, Вас, помочь?

Ситуация - Zywall L2TP работает(с винды подключаюсь) а вот с аналогичными настройками Keenetic не хочет пишет не готов.

Цитата

Jan 13 13:09:21ndm

Network::Interface::Supplicant: authnentication is unchanged.

Jan 13 13:09:21ipsec

08[KNL] interface ppp0 activated

Jan 13 13:09:21ndm

Network::Interface::Base: "L2TP0": interface is up.

Jan 13 13:09:21ndm

Network::Interface::Base: "L2TP0": description saved.

Jan 13 13:09:21ndm

Network::Interface::PPP: "L2TP0": disabled connection.

Jan 13 13:09:21ndm

Network::Interface::PPP: "L2TP0": peer set.

Jan 13 13:09:21ndm

Network::Interface::PPP: "L2TP0": disabled connection.

Jan 13 13:09:21ndm

Network::Interface::IP: "L2TP0": interface is non-global.

Jan 13 13:09:21ndm

Network::Interface::IP: "L2TP0": IP address cleared.

Jan 13 13:09:21ndm

Network::Interface::PPP: remote address erased.

Jan 13 13:09:21ndm

Network::Interface::Supplicant: identity is unchanged.

Jan 13 13:09:21ndm

Network::Interface::Schedule: removed schedule from to L2TP0.

Jan 13 13:09:21ndm

Dns::InterfaceSpecific: static name server list cleared on L2TP0.

Jan 13 13:09:21ndm

Core::ConfigurationSaver: saving configuration...

Jan 13 13:09:22ndm

Network::Interface::L2TP: "L2TP0": updating IP secure configuration.

Jan 13 13:09:22ndm

IpSec::Manager: IP secure connection "L2TP0" and keys was deleted.

Jan 13 13:09:22ndm

IpSec::Manager: IP secure connection "L2TP0" was added.

Jan 13 13:09:24ndm

IpSec::Manager: create IPsec reconfiguration transaction...

Jan 13 13:09:24ndm

IpSec::Manager: IPsec crypto map "Elle" administratively disabled, skipping.

Jan 13 13:09:24ndm

IpSec::Manager: IPsec reconfiguration transaction was created.

Jan 13 13:09:24ndm

IpSec::Configurator: start applying IPsec configuration.

Jan 13 13:09:24ndm

IpSec::Configurator: IPsec configuration applying is done.

Jan 13 13:09:24ndm

IpSec::Configurator: start reloading IPsec config task.

Jan 13 13:09:24ipsec

00[DMN] signal of type SIGHUP received. Reloading configuration

Jan 13 13:09:24ipsec

11[CFG] received stroke: add connection 'L2TP0'

Jan 13 13:09:24ipsec

11[CFG] added configuration 'L2TP0'

Jan 13 13:09:24ipsec

00[CFG] loaded 0 entries for attr plugin configuration

Jan 13 13:09:24ndm

IpSec::IpSecNetfilter: start reloading netfilter configuration...

Jan 13 13:09:24ndm

IpSec::Configurator: reloading IPsec config task done.

Jan 13 13:09:24ndm

IpSec::IpSecNetfilter: netfilter configuration reloading is done.

Jan 13 13:09:25ipsec

10[CFG] received stroke: initiate 'L2TP0'

Jan 13 13:09:25ipsec

12[IKE] sending DPD vendor ID

Jan 13 13:09:25ipsec

12[IKE] sending FRAGMENTATION vendor ID

Jan 13 13:09:25ipsec

12[IKE] sending NAT-T (RFC 3947) vendor ID

Jan 13 13:09:25ipsec

12[IKE] sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID

Jan 13 13:09:25ipsec

Jan 13 13:09:25ndm

IpSec::Configurator: crypto map "L2TP0" initialized.

Jan 13 13:09:25ipsec

09[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID

Jan 13 13:09:25ipsec

09[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID

Jan 13 13:09:25ipsec

09[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID

Jan 13 13:09:25ipsec

09[IKE] received NAT-T (RFC 3947) vendor ID

Jan 13 13:09:25ipsec

09[IKE] received DPD vendor ID

Jan 13 13:09:25ipsec

09[CFG] received proposals: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#

Jan 13 13:09:25ipsec

09[CFG] configured proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#

Jan 13 13:09:25ipsec

09[CFG] selected proposal: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#

Jan 13 13:09:25ndm

Core::ConfigurationSaver: configuration saved.

Jan 13 13:09:25ipsec

08[IKE] linked key for crypto map 'L2TP0' is not found, still searching

Jan 13 13:09:25ipsec

07[IKE] message verification failed

Jan 13 13:09:25ipsec

07[IKE] ignore malformed INFORMATIONAL request

Jan 13 13:09:25ipsec

07[IKE] INFORMATIONAL_V1 request with message ID 2386516089 processing failed

Jan 13 13:09:25ndm

IpSec::Configurator: IKE message parsing error for crypto map "L2TP0".

Jan 13 13:09:25ndm

IpSec::Configurator: (possibly because of wrong pre-shared key).

Jan 13 13:09:25ndm

IpSec::Configurator: fallback peer is not defined for crypto map "L2TP0", retry.

Jan 13 13:09:25ndm

Network::Interface::L2TP: "L2TP0": IPsec layer is down, shutdown L2TP layer.

Jan 13 13:09:25ndm

IpSec::Configurator: schedule reconnect for crypto map "L2TP0".

Jan 13 13:09:25ndm

Network::Interface::PPP: "L2TP0": disabled connection.

Jan 13 13:09:25ndm

Network::Interface::PPP: "L2TP0": disabled connection.

 

Edited February 9, 2017 by toga
Добавил журнал

[r13]

@Le ecureuil Добрый вечер, прикрутил свежеполученную экстру в качестве точки доступа(настроенной вручную)

Сейчас схема такая:

Есть Удаленная ультра и локальная ультра2 между ними поднят ipsec туннель.

К локальной ультре2 подключена экстра.

Возможно ли поднять EoIP туннель между экстрой и удаленной ультрой?

Edited January 13, 2017 by r13

[pdn_mail]

Добрый день!

На моей Giga II используется NAT. У меня вопрос по автоматической настройке EoIP over IPSec туннеля. Поднимаю интерфейс и что вижу:

Connections:
       EoIP0:  %any...%any  IKEv1, dpddelay=30s
       EoIP0:   local:  [48.210.2.2] uses pre-shared key authentication
       EoIP0:   remote: uses pre-shared key authentication
       EoIP0:   child:  48.210.2.2/32[gre] === 0.0.0.0/0[gre] TRANSPORT, dpdaction=restart

IPSec туннель в автоматическом режиме настраивается как транспорт, следовательно туннель у меня с NAT на роутере работать не будет?

 

[r13]

Если у сервера будет белый ip то заработает. 

[pdn_mail]

В том-то и дело что у сервера (на роутере) белый IP с NAT, клиент-же, который поднимает соединение, сидит тоже за NAT с белым IP, и поэтому мне думается не работает.

Получаю - 

Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for '48.210.2.2'[46.241.10.2] - '(null)'[212.20.13.66]

Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for 48.210.2.2 - 212.20.13.66

[r13]

Не понятно что такое "у сервера (на роутере) белый IP с NAT" 

[Le ecureuil]

В 1/13/2017 в 21:34, r13 сказал:

@Le ecureuil Добрый вечер, прикрутил свежеполученную экстру в качестве точки доступа(настроенной вручную)

Сейчас схема такая:

Есть Удаленная ультра и локальная ультра2 между ними поднят ipsec туннель.

К локальной ультре2 подключена экстра.

Возможно ли поднять EoIP туннель между экстрой и удаленной ультрой?

Да, в случае с EoIP/IPsec все возможно.

[Le ecureuil]

8 часов назад, pdn_mail сказал:

Добрый день!

На моей Giga II используется NAT. У меня вопрос по автоматической настройке EoIP over IPSec туннеля. Поднимаю интерфейс и что вижу:

Connections:
       EoIP0:  %any...%any  IKEv1, dpddelay=30s
       EoIP0:   local:  [48.210.2.2] uses pre-shared key authentication
       EoIP0:   remote: uses pre-shared key authentication
       EoIP0:   child:  48.210.2.2/32[gre] === 0.0.0.0/0[gre] TRANSPORT, dpdaction=restart

IPSec туннель в автоматическом режиме настраивается как транспорт, следовательно туннель у меня с NAT на роутере работать не будет?

 

У сервера должен быть "белый" адрес, клиент же может быть где угодно. Опишите подробнее, как у вас подключены к Интернету клиент и сервер.

[pdn_mail]

19 часов назад, Le ecureuil сказал:

У сервера должен быть "белый" адрес, клиент же может быть где угодно. Опишите подробнее, как у вас подключены к Интернету клиент и сервер.

 

В 15.01.2017 в 16:32, r13 сказал:

Не понятно что такое "у сервера (на роутере) белый IP с NAT" 

Вопрос вывел в отдельную тему - https://forum.keenetic.net/topic/1673-как-на-linux-с-помощью-strongswan прокинуть-туннель-eoip-over-ipsec-до-модема/

Может поможете?

[r13]

@pdn_mail,   @Le ecureuil Уже отписался в вашей теме, думаю стоит дождаться результатов его тестирования.

[Le ecureuil]

В 1/13/2017 в 12:02, toga сказал:

что - то не нашел ни каких внятных настроек, можно попросить, Вас, помочь?

Ситуация - Zywall L2TP работает(с винды подключаюсь) а вот с аналогичными настройками Keenetic не хочет пишет не готов.

 

Исправлено, появится в свежих сборках.

[Le ecureuil]

В 1/10/2017 в 19:25, distinctive сказал:

По моей проблеме будут комментарии или создавать отдельную тему?

Проблема в работе, думаем как ее аккуратно решить.

[Le ecureuil]

В 12/31/2016 в 18:43, KorDen сказал:

Что-то я не пойму. Попробовал настроить два IPIP (на "сервере") - второй подключающийся все равно цепляется на IPIP0, и второй туннель вроде как не поднимается. Если попробовать просто разные IP в рамках IPIP0 (как с PPTP-сервером), то тоже не работает.

Так все-таки, возможно ли сделать несколько соединений IPIP over IPsec (или IPIP и EoIP), для которых "сервером" будет один роутер, и как правильно это сделать?

До кучи: ради интереса попробовал мельком на "клиенте" сделать IPIP0 соединением по-умолчанию (ip global 1000) - вроде как не взлетело, основным так и осталось IPoE, хотя у него был стандартный вес 700. Посмотрел пару минут, сделал up/down, так ничего не получил, убрал.

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

[Le ecureuil]

В 12/23/2016 в 15:13, KorDen сказал:

Итак, имеется следующая конфигурация: (везде туннели поверх IPsec, 2.08.A.12.0-4, crypto engine hardware)

Ultra II (U2) - "сервер", 192.168.0.1/24
Giga II (G2-1) - подключается к U2 по IPIP0, 192.168.1.1/24
Giga II (G2-2) - сброшен в дефолт, настроен интернет, в Home отключен DHCP-сервер, 192.168.0.101/24, подключается к U2 по EoIP0, с обоих сторон прибриджован в Home. Первоначально тут планировался микротик, пока для тестов поставил гигу.

До начала настройки EoIP-туннеля IPIP0 работал корректно.

Первый и основной вопрос: могут ли одновременно работать EoIP over IPsec и IPIP over IPsec? А то он в логах при подключении IPIP пишет "ipsec: 07[IKE] IKE_SA EoIP0[6] established between ....", и пока на сервере включен EoIP0, IPIP0 вроде поднимается, но пакеты не идут.

Далее: Что делать с MTU в EoIP? Ничего специально не шаманил, а с ПК за G2-2 не открываются сайты, в частности HTTPS (скажем в Firefox этот форум не открывается, яндекс открывается с трудом, steamcommunity.com открывается нормально), и не ходят пинги 1400 пакетами.

На этой конфигурации словил один раз ребут G2-2, когда с ПК за G2-2 попытался зайти по самбе по NetBios-имени на ПК, подключенный к U2. U2 при этом не перезагрузился. Случилось один раз, повторить не удалось.

Селфтесты со всех роутеров будут ниже.

Опять-таки нет, автоматический туннель в серверном режиме только один

MTU должен был выставиться автоматом в 1380 (плюс-минус), попробуйте руками задать 1280 - с этим значением все должно работать. Ну и еще ip tcp adjust-mss pmtu на EoIP-интерфейсе, возможно только этого будет достаточно, или более жесткий вариант с ip tcp adjust-mss 1200.

[KorDen]

В 22.12.2016 в 17:40, Le ecureuil сказал:

Я вроде уже не раз писал, что у всех серверов должны совпадать IKE proposal, IKE PSK, IKE mode, иначе будет беда.

На всякий случай, хотелось бы уточнить, чтобы не тратить время на поиск того чего быть не может: все это верно так же и для ручного режима, или есть оговорки? Если, скажем, я хочу сделать на одном роутере несколько ручных транспортов точка-точка и VirtualIP-сервер для смартфонов - это вообще возможно? Во всех случаях должны быть одни и те же параметры первой фазы?

[Le ecureuil]

7 часов назад, KorDen сказал:

На всякий случай, хотелось бы уточнить, чтобы не тратить время на поиск того чего быть не может: все это верно так же и для ручного режима, или есть оговорки? Если, скажем, я хочу сделать на одном роутере несколько ручных транспортов точка-точка и VirtualIP-сервер для смартфонов - это вообще возможно? Во всех случаях должны быть одни и те же параметры первой фазы?

Для серверов - да.

[KorDen]

8 часов назад, Le ecureuil сказал:

Для серверов - да.

Т.е., (еще раз для завершения картинки в голове) я правильно понимаю, что если с обоих сторон будет прямая видимость и указаны set-peer 1.2.3.4 (а не set-peer any на "сервере"), то параметры таких туннелей могут быть индивидуальными, в таком случае на этом роутере едиными должны быть только параметры для VirtrualIP-сервера и туннеля-"сервера" для клиента за NAT?

И в автоматическом режиме такое изначально невозможно, т.к. один из пиров обязательно должен являться сервером, два tunnel destination быть не может, так?

Edited January 20, 2017 by KorDen

[Le ecureuil]

В 1/20/2017 в 18:43, KorDen сказал:

Т.е., (еще раз для завершения картинки в голове) я правильно понимаю, что если с обоих сторон будет прямая видимость и указаны set-peer 1.2.3.4 (а не set-peer any на "сервере"), то параметры таких туннелей могут быть индивидуальными, в таком случае на этом роутере едиными должны быть только параметры для VirtrualIP-сервера и туннеля-"сервера" для клиента за NAT?

И в автоматическом режиме такое изначально невозможно, т.к. один из пиров обязательно должен являться сервером, два tunnel destination быть не может, так?

Конфигурации с set-peer на обоих сторонах не спасут ситуацию, вам нужно чтобы сервер цеплялся к вам (тогда фактически он будет клиентом множества туннелей), но это возможно только если есть прямая видимость удаленных узлов.

[KorDen]

@Le ecureuil Теперь я еще больше запутался :\

Скрытый текст

Для всех туннелей между роутерами есть прямая видимость в обе стороны, статические IP, у роутеров не пересекающиеся локальные подсети. Нужно чтобы все локалки видели друг друга (в том числе #3-#5 через 3-1-2-5), поэтому я склоняюсь к IPIP поверх ручного транспорта IPsec, без серверов. #1-#2 - кинетики, остальное - кинетики/микротики.

Плюс есть road-warrior'ы за всевозможными NAToverNATbehindNAT, для них и нужен сервер(ы), скорее всего VirtualIP. В принципе не критично, если закинуть их только на #1 или #2.

Возможно ли для межроутерных туннелей использовать одни параметры (в частности, ключ) первой фазы, а для удаленщиков - другие? Или все должно совпадать везде?

Edited January 23, 2017 by KorDen

[Le ecureuil]

5 минут назад, KorDen сказал:

@Le ecureuil Теперь я еще больше запутался :\

  Скрыть содержимое

Для всех туннелей между роутерами есть прямая видимость в обе стороны, статические IP, у роутеров не пересекающиеся локальные подсети. Нужно чтобы все локалки видели друг друга, поэтому я склоняюсь к IPIP поверх ручного транспорта IPsec, без серверов. #1-#2 - кинетики, остальное - кинетики/микротики.

Плюс есть road-warrior'ы за всевозможными NAToverNATbehindNAT, для них и нужен сервер(ы), скорее всего VirtualIP. В принципе не критично, если закинуть их только на #1 или #2.

Возможно ли для межроутерных туннелей использовать одни параметры (в частности, ключ) первой фазы, а для удаленщиков - другие? Или все должно совпадать везде?

Если ноды 1 и 2 будут только VIP-серверами, а соединения для туннелей будут устанавливать ноды 1 и 2 в клиентском режиме к нодам 3-4-5 (они будут серверами), то тогда все отлично.

[KorDen]

2 минуты назад, Le ecureuil сказал:

Если ноды 1 и 2 будут только VIP-серверами, а соединения для туннелей будут устанавливать ноды 1 и 2 в клиентском режиме к нодам 3-4-5 (они будут серверами), то тогда все отлично.

Режим "клиент-сервер" не нравится по одной причине - при set-peer с обоих сторон любая из сторон начинает устанавливать соединение с удаленной как только начинает идти трафик. А в клиент-серверном, если скажем перезагрузить ноду 3, надо ждать, пока 1 переподключится к ней. Насколько я понял, в таком виде придется везде использовать единый ключ и версию IKE?

[Le ecureuil]

44 минуты назад, KorDen сказал:

Режим "клиент-сервер" не нравится по одной причине - при set-peer с обоих сторон любая из сторон начинает устанавливать соединение с удаленной как только начинает идти трафик. А в клиент-серверном, если скажем перезагрузить ноду 3, надо ждать, пока 1 переподключится к ней. Насколько я понял, в таком виде придется везде использовать единый ключ и версию IKE?

В таком режиме да, причем не только версию IKE (только IKEv1), но и общий PSK для всех из них, и общий IKE proposal, и нужно использовать ID сторон в виде IP-адресов (ограничение протокола IKEv1). В таком случае все реально.

[KorDen]

3 часа назад, Le ecureuil сказал:

только IKEv1

Это только из-за VIP, или есть и другие причины?

[Le ecureuil]

19 часов назад, KorDen сказал:

Это только из-за VIP, или есть и другие причины?

Все автоматические туннели ради совместимости с Mikrotik, Cisco и ZyWall, а также Virtual IP (он же Cisco IPsec) требуют IKEv1.

Если все делать руками, то да, можно и на IKEv2 спокойно перейти.

[toga]

В 08.11.2016 в 12:59, Le ecureuil сказал:

Ручной режим здесь описан не будет, поскольку продвинутые юзеры сами всегда могут сперва настроить IPsec с правильным режимом, а затем поверх IPsec поднять туннель.

а можно это хоть немного расписать? или ссылку попросить, где нарыть можно.

[KorDen]

11 минуту назад, toga сказал:

а можно это хоть немного расписать

Создаете через веб транспорт, удаленные подсети ставите любые. Дальше уже через консоль меняете access-list для этого подключения на что-то вроде

permit ipip 3.3.3.3 255.255.255.255 1.1.1.1 255.255.255.255

дальше настраиваете туннель без шифрования...

Чисто теоретически можно было бы указать удаленной подсетью удаленный IP с маской 255.255.255.255 и локальной - исходящий IP, но тогда ничего не будет работать и удаленный доступ к роутеру сломается.

[toga]

Ура!!! У меня получилось приручить этого зверя!!! выложу тут, вдруг кому нибудь пригодится и он будет так же бороздить интернет по запросу Gre over IPsec Zyxel USG 310 60 110.

И так для настройки нам потребуется само железо

1) Представительство компании Zyxel, предоставила на тестирование USG 310 но думаю будет работать и с другими  представителями линейки. в тех поддержке сказали:

Цитата

возможность поднять GRE over IPSec есть только в новом поколении устройств: https://zyxel.ru/catalog/business/security/usg (кроме USG 1000\2000).

2) Мы приобрели Keenetic Giga III

Настройка ZyWall:

для начала поднимает IPsec делал все по статьям из бз

Configuration > VPN > IPSec VPN > VPN Gateway

У кенетика будет динамический ip поэтому регистрируем его не no-ip и прописываем dns имя в статический адрес

Так же вводим ключ PSK и выбираем нужные

 

 

Configuration > VPN > IPSec VPN > VPN Connection

Ставим галочку постоянное соединений, выбираем наш шлюз VPN.

а вот в локальная и удаленная подсеть вбиваем интерфейсы, между которыми будет поднят Gre туннель. Далее ставим галочку Активировать Gre over IPSec

Network > Interface > Tunnel

Устанавливаем тип Gre, Настройка параметров IP: ip адрес - интерфейса gre

Настройка шлюза:

1) не удалось поднять тунель, если указать интерфейс поэтому ввел ip руками. отписался в ТП

2) Ip-адрес удаленного шлюза - IP интерфейса Keenetic

для проверки и детектирования канала можно включить проверку соединения.

Настройка Keenetic:

Безопасность > IPsec VPN > Добавть

Настраиваем исходя из статья бз: указываем удаленный шлюз, методы шифрования Ключ PSK

в пункте IP-адрес локальной и удаленной сети указываем подсеть (оканчивается на 0).

Далее спомощью PuTTY или другого клиента подключаемся к Keenetic по telnet

и выполняем следующие действия

 access-list Ipsec
 permit ip 10.11.1.1 255.255.255.0 10.10.251.1 255.255.255.0
 exit
 crypto map Ipsec
 match-address Ipsec
 exit
 
 interface Gre0
 ip address 10.12.1.2 255.255.255.252
 ip mtu 1476
 tunnel source 10.11.1.1
 tunnel destination 10.10.251.1
 security-level private
 

ну и на последок

no isolate-private

на счет последнего не уверен, но трафик с машин пошел, только когда его включил)

ну и в заключении статическую маршрутизацию с кинетика в нутрь нашей сети.

[Le ecureuil]

5 минут назад, toga сказал:

Ура!!! У меня получилось приручить этого зверя!!! выложу тут, вдруг кому нибудь пригодится и он будет так же бороздить интернет по запросу Gre over IPsec Zyxel USG 310 60 110.

И так для настройки нам потребуется само железо

1) Представительство компании Zyxel, предоставила на тестирование USG 310 но думаю будет работать и с другими  представителями линейки. в тех поддержке сказали:

2) Мы приобрели Keenetic Giga III

Настройка ZyWall:

для начала поднимает IPsec делал все по статьям из бз

Configuration > VPN > IPSec VPN > VPN Gateway

У кенетика будет динамический ip поэтому регистрируем его не no-ip и прописываем dns имя в статический адрес

Так же вводим ключ PSK и выбираем нужные

 

 

Configuration > VPN > IPSec VPN > VPN Connection

Ставим галочку постоянное соединений, выбираем наш шлюз VPN.

а вот в локальная и удаленная подсеть вбиваем интерфейсы, между которыми будет поднят Gre туннель. Далее ставим галочку Активировать Gre over IPSec

Network > Interface > Tunnel

Устанавливаем тип Gre, Настройка параметров IP: ip адрес - интерфейса gre

Настройка шлюза:

1) не удалось поднять тунель, если указать интерфейс поэтому ввел ip руками. отписался в ТП

2) Ip-адрес удаленного шлюза - IP интерфейса Keenetic

для проверки и детектирования канала можно включить проверку соединения.

Настройка Keenetic:

Безопасность > IPsec VPN > Добавть

Настраиваем исходя из статья бз: указываем удаленный шлюз, методы шифрования Ключ PSK

в пункте IP-адрес локальной и удаленной сети указываем подсеть (оканчивается на 0).

Далее спомощью PuTTY или другого клиента подключаемся к Keenetic по telnet

и выполняем следующие действия

 access-list Ipsec
 permit ip 10.11.1.1 255.255.255.0 10.10.251.1 255.255.255.0
 exit
 crypto map Ipsec
 match-address Ipsec
 exit
 
 interface Gre0
 ip address 10.12.1.2 255.255.255.252
 ip mtu 1476
 tunnel source 10.11.1.1
 tunnel destination 10.10.251.1
 security-level private
 

ну и на последок

no isolate-private

на счет последнего не уверен, но трафик с машин пошел, только когда его включил)

ну и в заключении статическую маршрутизацию с кинетика в нутрь нашей сети.

По-хорошему нужно сделать access-list вот таким:

 permit gre 10.11.1.1 255.255.255.0 10.10.251.1 255.255.255.0

И проверить на работоспособность.

Ну и неплохо бы использовать транспортный режим вместо туннельного для уменьшения overhead, и в транспортном режиме permit gre обязателен.

[toga]

2 минуты назад, Le ecureuil сказал:

 permit gre 10.11.1.1 255.255.255.0 10.10.251.1 255.255.255.0

И проверить на работоспособность.

так не заработал.

На счет транспортного режима, чуть по позже попробую пока сил не осталось)