В чем проблема с подключением к ipsec+ikev2 через сертификаты?

Question

[littleguga]

Смотрю wireshark'ом на клиенте и tcpdump'ом на сервере.

Проходит так:
клиент запрашивает у сервера ikev_init
сервер отвечает
клиент отправляет свой сертификат и поддерживаемые шифры
сервер их получает и отправляет ответ
клиент не получает этот ответ! (в некоторых сетях тот же самый клиент получает его и тогда подключение к VPN проходит успешно)

Сервер отправляет пакет, но на клиент он не доходит:

mysite = домен моего сервера
clientdomain - мой клиент

17:27:23.187306 IP (tos 0x0, ttl 64, id 48370, offset 0, flags [DF], proto UDP (17), length 365)
    mysite.isakmp > clientdomain.432: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[R]:
    (sa: len=44
        (p: #2 protoid=isakmp transform=4 len=44
            (t: #1 type=encr id=aes (type=keylen value=0100))
            (t: #2 type=integ id=hmac-sha )
            (t: #3 type=prf id=hmac-sha )
            (t: #4 type=dh id=modp1024 )))
    (v2ke: len=128 group=modp1024)
    (nonce: len=32 data=(c4a4d5aed36e40823c9a...bf291b136ca24898abf4000b0000000800004014))
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (v2cr: len=21)
    (n: prot_id=#0 type=16404(status))

На клиенте wireshark'ом этого пакета нет, остальные есть:


В чем может быть проблема?

Такое в некоторых сетях(2ком, некоторые от мгтс). В некоторых сетях от мгтс данный волшебный пакетик доходит и тогда к VPN подключается успешно.

Answer 1

[athacker]

Есть основания полагать, что это криво настроенный ALG на сети провайдера. У вас клиент за провайдерским NAT'ом, и этот NAT режет пакеты. У Онлайма в сети такое происходит с L2TP -- сервер шлёт пакет согласования параметров соединения, клиент его получает и ОТВЕЧАЕТ. Но до сервера ответ не доходит. Вывод -- режется провайдером. Бороться с этим, вероятнее всего, бесполезно. Я с онлаймом с апреля бодаюсь по этому поводу. "Ваше обращение передано в профильный отдел, бла-бла-бла". Причём какой конкретно отдел является "профильным" -- они не говорят. Ну то есть, иными словами, болт они кладут на такие заявки, и ни в какие "профильные отделы" оно не перенаправляется.

В вашем случае выход -- строить IPSec в другом туннеле -- L2TP или PPTP.

Comments

[littleguga]

А можете подсказать, как ipsec+l2tp+ikev2? А то для l2tp он предлагает использовать не strongswan(либо неправильно гуглю)

[athacker]

littleguga: Так в чём вопрос-то? Что значит "как ipsec+l2tp+ikev2", и кто "он" предлагает использовать не strongswan? :-)

[littleguga]

athacker: он - гугл(по другому сформулировал вопрос в начале и забыл поменять).

https://habrahabr.ru/post/250859/
raymii.org/s/tutorials/IPSEC_vpn_with_Ubuntu_16.04.html

И похожих статей/гайдов еще много. Везде strongswan и без L2TP.

[littleguga]

athacker: l2tp+ipsec нашел вот здесь: https://github.com/hwdsl2/setup-ipsec-vpn
Но там используется не strongswan и нет поддержки ikev2

[athacker]

littleguga: Связка L2TP/IPSec в общем случае (в винде, например), работает по-другому. Там L2TP трафик шифруется с помощью IPSeс. У вас же, в свете проблем с хождением IPSec по сети провайдера, нужно делать наоборот -- СНАЧАЛА поднимать L2TP-туннель, а уже трафик ВНУТРИ туннеля шифровать IPSec'ом. Так что L2TP можете поднимать на чём угодно, это никакого значения не имеет. Потом просто распишете policy в настройках Strongswan таким образом, чтобы трафик внутри L2TP-туннеля шифровался.

[littleguga]

athacker: к сожалению, я не очень прошаренный в таких вещах, так что очень бы помогла wiki/guide.

Правильно ли я понял:
Нужно поднять l2tp туннель с помощью чего-угодно(что порекомендуете?)
уже внутри этого туннеля поднимать шифрование(тогда тут не понимаю, как заставить strongswan, например, влезать в этот туннель?)

[athacker]

littleguga: IPSec -- это вообще тема сложная :-) Наш отдел сети передачи данных начинает томно заказывать глаза, когда я поднимаю вопрос про IPSec :-) Так что вики/гайды тут только на уровне "вбейте вот этот набор команд, и у вас заработает". По факту -- вряд ли оно заработает так быстро :-)

L2TP можете строить чем угодно, да. Какой софт вам покажется проще и удобнее -- тем и стройте.

IPSec определяет, какой трафик шифровать, на основе policy. Полиси включает в себя набор IP-адресов и/или подсетей и список портов. То есть, в полиси можно указать: "трафик между такой-то и такой-то подсетью необходимо шифровать". И тогда туннель будет строиться на L2TP, а внутри него трафик уже будет шифроваться IPSec'ом.

В стронгсване это делается так:

conn hm
left=192.168.3.1
leftsubnet=192.168.4.17/32
right=192.168.17.50
rightsubnet=192.168.1.0/28
type=tunnel
auto=start

leftsubnet и rightsubnet -- это те сети, между которыми будет шифроваться трафик.

[littleguga]

athacker: понял, попробую, отпишу. Спасибо огромное, Вам!

Answer 2

[Oleg1345140]

Была подобная проблема с местным провайдером (как athacker написал), решилось буквально за пару дней общения с провайдером, объяснил в чем проблема, сказали посмотрят и позднее написали что поправили проблему на своей стороне. Работает уже несколько лет.

Answer 3

[Alexander_O]

Недавно был вынужден временно переключиться на злополучный МГТС*, и тоже столкнулся со схожей проблемой. IKEv2 RSA не работает на Windows, в то время как L2TP+IPsec (IKEv1 PSK) спокойно заводилось. При этом на iOS 11.1 beta 5 IKEv2 RSA также спокойно заводилось.

После проверки через WireShark выяснилось, что пакеты в сети МГТСа фрагментируются (забегая вперёд скажу сразу, что принудительное понижение MTU на клиентском интерфейсе ни к чему не привело).
(естественно это было бы невозможно выявить при использовании жёсткого фильтра на порты UDP 500 и 4500, как это было показано на скриншоте в изначальном вопросе)

И с этим вроде бы должна справляться опция fragmentation = yes на стороне strongSwan, однако Windows 10, по всей видимости, так и не научилась работать с фрагментированными пакетами в IKEv2:

Windows clients support IKEv1 fragmentation, but not IKEv2 fragmentation.

© https://wiki.strongswan.org/projects/strongswan/wi...

* — после подключения белого IP-адреса (МГТС по умолчанию всех прячет за NAT) указанная проблема исчезла.

Answer 4

[Андрей]

Попробуйте проверить MTU

Comments

[littleguga]

Пакеты по 1500 (сертификат + шифры) проходят спокойно. + на скрине видно, что пакет длиной 379 от сервера пришел спокойно.
А этот пакет длиной 365 не доходит.

[Андрей]

А с номерами портов что в этих пакетах ? Не может ли это быть следствием NAT-а или некорректного protocol inspection ?

[littleguga]

Андрей: на скрине порты сервера, к которым обращается клиент.

На клиент все пакеты идут через рандомный 40к+ порт (каждый раз по разному). Все ходят через один порт(от сервера к клиенту)