IPSec(Cisco) + Keenetic 4G III + "чудесатый оператор LTE"

[SerjioS]

Дня!

 

Для связи удалённых площадок с центром использую связку Cisco 881 + Keenetic 4G III (rev.B, release: 2.15.C.4.0-1) c USB-LTE модемом, поверх этого бегает IPSec (DMVPN). Однако, с Апреля начались "чудеса" с одним из операторов сотовой связи - перестал проходить IPSec (DMVPN).

 

Как показал анализ трафика - пакеты (UDP/500) просто не доходят до центра. "Зачем и почему" - техподдержка оператора реагирует в высшей степени неторопливо и занимается какой-то дурью типа "почему у вас на динамическом(!) подключении... меняется IP-адрес" (я серьёзно, это практически цитата).

 

Из-за этого пришлось искать "заплатку" на стороне Keenetic. "Пляски с бубном" выдали два варианта решения:

1. Откат на сильно более раннюю прошивку - 2.7.х и ниже.
2. Через CLI включать в конфигурацию (config)> ip nat udp-port-preserve

Кстати, попутно выяснилось ещё несколько "чудесатых" условий:

• проблемы есть в нескольких регионах и только с одним конкретным оператором;
• при установке в тот же USB-модем SIM-карты от другого оператора - IPSec (DMVPN) восстанавливается, даже перезапускать оборудование не приходится;
• проблемы есть при использовании динамического IP, т.е. если на SIM-карту подключить фиксированный IP и прописать соответствующий APN - связь, опять же, восстанавливается, без перезагрузки.

С учётом, что до этого несколько лет такая схема работала без проблем, то с "моей колокольни" видится - источник проблемы где-то районе операторского CG NAT. Но время уходит, а оператор не может ни подтвердить ни опровергнуть это.

 

 

Версия Keenetic:

Spoiler

 

config)> show ver

          release: 2.15.C.4.0-1
             arch: mips

              ndm:
                exact: 0-91000d4
                cdate: 11 May 2019

              bsp:
                exact: 0-1767f78
                cdate: 13 May 2019

              ndw:
              version: 1.6.27
             features: wifi_button,single_usb_port,dual_image,wifi_ft
           components: base,dhcpd,miniupnpd,monitor,nathelper-pptp,
                       pingcheck,ppe,usb,usblte,usbmodem,usbnet

     manufacturer: ZyXEL
           vendor: ZyXEL
           series: Keenetic series
            model: Keenetic
       hw_version: 01130000-B
            hw_id: kg_rh
           device: Keenetic 4G III
            class: Internet Center
           region: RU
      description: ZyXEL Keenetic

 

 

[Usatyj]

Почему бы не назвать оператора, думаю информация была бы не бесполезной.

[SerjioS]

16 hours ago, Usatyj said:

Почему бы не назвать оператора, думаю информация была бы не бесполезной.

МегаФон это. Регионы, где столкнулись с этим: СПб, Москва, Московская, Ленинградская, Мурманская и Ярославская области.

Кстати, про их тех. поддержку - раньше у них такой "упёртости" не замечал. До этого возникали пару раз серьёзные вопросы - решилась оперативно. Хз, что на них нашло в этот раз.

[Елена Фадеева]

4 часа назад, SerjioS сказал:

МегаФон это. Регионы, где столкнулись с этим: СПб, Москва, Московская, Ленинградская, Мурманская и Ярославская области.

Кстати, про их тех. поддержку - раньше у них такой "упёртости" не замечал. До этого возникали пару раз серьёзные вопросы - решилась оперативно. Хз, что на них нашло в этот раз.

Здравствуйте! Напишите, пожалуйста, о сложившейся ситуации в личные сообщения наших аккаунтов ВКонтакте (vk.com/megafon), Facebook (facebook.com/MegaFon.ru) или Твиттер (twitter.com/megafonru). Обязательно во всем разберемся!

[KorDen]

В 23.05.2019 в 16:13, SerjioS сказал:

Как показал анализ трафика - пакеты (UDP/500) просто не доходят до центра

UDP/500 - т.е. установка соединения вообще не начинается? Или всё-таки что-то начинается, но потом тухнет (где-то забыли включить NAT-T?)

ip nat udp-port-preserve проблему решает, или нет/не везде/частично? Компонент IPsec на кинетике установлен или нет?

IPsec довольно капризная штука. И да, некоторые провайдерские CG-NAT его умудряются ломать так или иначе. Можно еще вспомнить МТС с поломаной фрагментацией пакетов (хотя может уже починили). Увы, с учетом нынешнего состояния тех.блока опсосов решать подобные технические проблемы очень затруднительно.

[Usatyj]

9 часов назад, SerjioS сказал:

МегаФон это. Регионы, где столкнулись с этим: СПб, Москва, Московская, Ленинградская, Мурманская и Ярославская области.

Кстати, про их тех. поддержку - раньше у них такой "упёртости" не замечал. До этого возникали пару раз серьёзные вопросы - решилась оперативно. Хз, что на них нашло в этот раз.

Спасибо. Полезная информация, особенно про техподдержку.

[SerjioS]

On 5/24/2019 at 6:47 PM, Елена Фадеева said:

Здравствуйте! Напишите, пожалуйста, о сложившейся ситуации в личные сообщения наших аккаунтов ВКонтакте (vk.com/megafon), Facebook (facebook.com/MegaFon.ru) или Твиттер (twitter.com/megafonru). Обязательно во всем разберемся!

Добрый день, я ещё с начала Апреля нахожусь в контакте и с техподдержкой (есть активная заявка) и с корпоративным менеджером. Пока что воз и ныне там.

Изменено 27 мая, 2019 пользователем SerjioS

[SerjioS]

On 5/24/2019 at 7:28 PM, KorDen said:

UDP/500 - т.е. установка соединения вообще не начинается? Или всё-таки что-то начинается, но потом тухнет (где-то забыли включить NAT-T?)

ip nat udp-port-preserve проблему решает, или нет/не везде/частично? Компонент IPsec на кинетике установлен или нет?

IPsec довольно капризная штука. И да, некоторые провайдерские CG-NAT его умудряются ломать так или иначе. Можно еще вспомнить МТС с поломаной фрагментацией пакетов (хотя может уже починили). Увы, с учетом нынешнего состояния тех.блока опсосов решать подобные технические проблемы очень затруднительно.

Про UDP/500 - соединение инициируется со стороны удалённой площадки. И на Cisco и на Zyxel дампы трафика это показывают. Раньше пакеты спокойно доходили до DMVPN Hub'а в центре. Сейчас до него пакеты просто не доходят. Только вот, ДО Апреля всё прекрасно работало. Сама схема отлажена и используется уже несколько лет - все необходимые NAT-T за это время были включены. Соответствующие опции присутствуют в пакетах, что видно при анализе дампов трафика.

Про ip nat udp-port-preserve - да, помогает всегда. Или так или подключать на SIM фиксированный IP (и прописывать соответствующую APN). Я пробовал и обычный IPSec и с IKEv2, увы. Ровно по этим же причинам компонента IPsec на кинетиках не установлено, собственно - уже после Апреля я поробовал его добавлять (и не только его) - бесполезно, в моём случае не помогло.

"IPsec довольно капризная штука. И да, некоторые провайдерские CG-NAT его умудряются ломать так или иначе" - истинно так. Жаль, нет более подробного описания опции "ip nat udp-port-preserve" глядишь, было бы понятно почему она помогает преодолевать CG NAT, и соответственно - что оператор мог поломать.

[KorDen]

24 минуты назад, SerjioS сказал:

ip nat udp-port-preserve - да, помогает всегда

Название опции говорит само за себя. При обычном прохождении NAT исходящий порт 500 заменяется на произвольный, а дальше возможно оператором еще раз меняется.

При включенной опции кинетик сохраняет исходящий порт 500, CG-NAT провайдера скорее всего тоже сохраняет его, и тогда всё ок. У вас в центре случаем никакого фаервола нет?

Вот старый топик по очень похожей ситуации, но там были проблемы другого рода - https://forum.keenetic.net/topic/2811-ipsec-туннель-через-keenetic/?tab=comments

 

Изменено 27 мая, 2019 пользователем KorDen

[Le ecureuil]

Есть опция forceencaps у crypto map для таких случаев. Плюс можно поиграться с ikev1/ikev2. Yota уже давно пытается через раз давать работать IKEv2, но ikev1 пока работает.

[r13]

Во и меня цепануло

Мегафон: исходящие ike запросы пропускает, входящие ответы фильтрует

Изменено 11 июня, 2019 пользователем r13

[Le ecureuil]

Я так подозреваю, что это в связи с массовым использванием IKEv2 для VPN у частников. IKEv1 не трогают, поскольку это как правило корпоративный необновляемый и старый как говно мамонта энтерпрайз, и его ломать не следует.

[SerjioS]

Пробовал я и IKEv1 и IKEv2. Никаких изменений.

Сейчас менеджер из Мегафона, с которым я общаюсь, в отпуске. Так что - пока пауза. По техническим вопросам идти на контакт их служба отказывается напрочь. Периодически продолжают изображать кипучую деятельность, н-р последний раз спросили настройки DMVPN. На вопрос - чего они там рассчитывают найти ТАКОГО - ответа я не получил (хотя я и писал изначально - конфигурация рабочая, её никто не менял несколько лет и "сломалось" всё в один день). Менеджером был предложен вариант некоей тарифной опции, как я понял - разновидность "белого" IP-адреса, для всё группы номеров, но "это не точно" и, блин, всё это ещё надо продавливать внутри самого Мегефона.

 

Изменено 13 июня, 2019 пользователем SerjioS

[SerjioS]

On 6/11/2019 at 11:56 PM, Le ecureuil said:

Я так подозреваю, что это в связи с массовым использванием IKEv2 для VPN у частников.

Согласен, у меня возникли те же подозрения. Хотя в данном случае у меня не работают обе редакции IKE.

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

[arka]

у меня на Yota 4g Wi-fi USB + Keenetic Giga не работает  IPSEC
Переключаемся на другого провайдера - работает. (через телефон например, в качестве Wireless ISP)

Не могу найти причину, не поднимается тоннель и всё. (на обоих концах 2х Giga Текущая версия KeeneticOS: 3.1.10)

может ли мне помочь 

ip nat udp-port-preserve  ?

сейчас

{
    "prompt": "(config)",
    "status": [
        {
            "status": "message",
            "code": "101122548",
            "ident": "Network::Nat",
            "source": "",
            "warning": "no",
            "message": "UDP port preserve enabled."
        }
    ]
}

Лог при этом

IpSec::Configurator: "tirstroyipsec": crypto map active IKE SA: 0, active CHILD SA: 0.
Ноя 8 16:07:48 ndm
IpSec::Configurator: fallback peer is not defined for crypto map "tirstroyipsec", retry.
Ноя 8 16:07:48 ndm
IpSec::Configurator: "tirstroyipsec": schedule reconnect for crypto map.
Ноя 8 16:07:48 ipsec
11[IKE] establishing IKE_SA failed, peer not responding
Ноя 8 16:08:04 ndm
IpSec::Configurator: reconnecting crypto map "tirstroyipsec".
Ноя 8 16:08:06 ndm
IpSec::Configurator: "tirstroyipsec": crypto map shutdown started.
Ноя 8 16:08:06 ipsec
12[CFG] received stroke: unroute 'tirstroyipsec'
Ноя 8 16:08:06 ipsec
13[CFG] received stroke: terminate 'tirstroyipsec{*}'
Ноя 8 16:08:06 ipsec
13[CFG] no CHILD_SA named 'tirstroyipsec' found
Ноя 8 16:08:06 ipsec
10[CFG] received stroke: terminate 'tirstroyipsec[*]'
Ноя 8 16:08:06 ipsec
10[CFG] no IKE_SA named 'tirstroyipsec' found
Ноя 8 16:08:06 ndm
IpSec::Configurator: "tirstroyipsec": crypto map shutdown complete.
Ноя 8 16:08:08 ipsec
06[CFG] received stroke: initiate 'tirstroyipsec'
Ноя 8 16:08:08 ndm
IpSec::Configurator: "tirstroyipsec": crypto map initialized.
Ноя 8 16:08:08 ipsec
07[IKE] initiating IKE_SA tirstroyipsec[673] to 1XX.XX.253.54
Ноя 8 16:08:16 ipsec
05[IKE] retransmit 1 of request with message ID 0
Ноя 8 16:08:25 ipsec
04[IKE] retransmit 2 of request with message ID 0
Ноя 8 16:08:35 ipsec
05[IKE] retransmit 3 of request with message ID 0
Ноя 8 16:08:46 ipsec
14[IKE] retransmit 4 of request with message ID 0
Ноя 8 16:08:57 ipsec
12[IKE] retransmit 5 of request with message ID 0
Ноя 8 16:09:10 ipsec
13[IKE] retransmit 6 of request with message ID 0
Ноя 8 16:09:24 ipsec
11[IKE] retransmit 7 of request with message ID 0
Ноя 8 16:09:40 ipsec
08[IKE] retransmit 8 of request with message ID 0
Ноя 8 16:09:57 ipsec
15[IKE] giving up after 8 retransmits
Ноя 8 16:09:57 ndm
IpSec::Configurator: remote peer of crypto map "tirstroyipsec" is down.