ipsec linux<>windows

дико интересно, подписался

Вся проблема оказалась в PFS. Виндовс ее тупо не поддерживает, по крайней мере по умолчанию. Пишут, что как-то можно включить, пока еще не разобрался. Пока сделал pfs=off и все работает. Будет настроение - покопаю дальше, чтобы включить PFS на windows. Фича очень нужная и полезная. Грубо говоря - ФБР перехватывает весь твой трафик и записывает. Потом однажды в критический момент комуниздят твой комп, берут оттуда rsa private key и расшифровывают весь записанный ранее трафик, где ты продаешь наркотики и выкладываешь ДП.

https://ru.wikipedia.org/wiki/Perfect_forward_secrecy

Вот так работает :

/etc/ipsec.conf :

config setup
    nat_traversal=yes
    interface=%defaultroute
    oe=off
conn myconnection
    type=transport
    left=192.168.2.5
    leftcert=server.cert
    leftid=%fromcert
    leftrsasigkey=%cert
    leftca=myca.cert
    right=bananos.org
    rightid=CN=bananos.org
    authby=rsasig
    ike=3des-sha1;modp1024
    pfs=no
    auth=esp
    dpdtimeout=120
    dpddelay=30
    dpdaction=restart_by_peer
    forceencaps=yes
    auto=start

/etc/ipsec.secrets :

: RSA /etc/ipsec.d/private/server.key

комуниздят твой комп

шо, там нету диффи-хельманов?

Я так понял, что без PFS достаточно одного приват кея, чтобы восстановить ключ сессии. С PFS нужны оба.

Не повезло вам, такой жалкий протоколишко навязали

Вообще-то, это общепринятый стандарт, а для ipv6 - обязательная часть IP протокола. Другое дело, почему в windows такая фигня по умолчанию. Если изъять оба приват ключа, то никакое самое правильное шифрование не поможет, потому что обмен ключами проходит по тому же самому каналу, что и данные.

Если потеря приват ключей критична, их нельзя хранить в виде файлов. Нужно пользоваться крипто-смарт-картами или крипто-токенами. Они никогда не отдают приват ключ, а только по запросу подписывают сообщения.

А если потеряешь смарткарту? Просто нужно хранить ключи в надёжном месте. И шифровать это место другими ключами. А их хранить в ещё более надёжном месте.

а эти ключи не страшно потерять. сертификат хоста можно перегенерить в любой момент

Ну тогда надо надёжно хранить ключи для перегенерации сертификатов хоста.

Инфы об ipsec на Linux + windows в нете совсем немного. Openswan как оказалось страдает еще одной проблемой. Через несколько минут отсутствия пакетов соединение отваливается на стороне винды. В oakley.log видим вот такое :

1-19: 13:37:28:955:310 CE Dead. sa:05585018 ce:000F35C0 status:35f0 1-19: 13:37:28:955:310 SA Dead. sa:05585018 status:35f0

В сниффере видно, как нормально со стороны linux идут NAT-T keepalive. Пока пингается - отсылаются ESP, принимаются ESP. Ждем минут 10. keep-alives по-прежнему идут, ESP отсылаются, винда на них никак не отвечает. То есть для нее мы мертвы. SA сдохло. Openswan не в состоянии распознать эту ситуацию и перенеготиэйтить SA. Dead peer detection виндой не поддерживается.

Как это лечить не знаю. Разве что параллельно с запуском SA еще и запускать вечный пинг. Но это не спасет от проблем с сетью, если вдруг по какой-то другой причине перестанут доходить пакеты.

Нигде не нашел лечения.

Опять пытался ковырять racoon. Пытался включить PFS на винде. Судя по всему MS и openswan понимают под этим понятием разные вещи. Потому что даже при включенном PFS на винде с опцией pfs=on на стороне openswan ничего не работает, с racoon ситуация тоже никак не меняется. В racoon застреваем на «IDci mismatched». Openswan на этот случай применяет какой-то свой microsoft bad proposal workaround, о чем говорит в логе. А ракун тупо идет в ошибку и все застревает. Где-то пишут, что надо накладывать какие-то патчи на racoon.

Короче, надежного решения я так и не нашел. Только решение «кое-как через ...»

А если генерить трафик между концами, то тоннель (при нормальной работе канала связи) не рвется?

Ждем минут 10. keep-alives по-прежнему идут, ESP отсылаются, винда на них никак не отвечает.

А в свановских логах при этом что-нибудь про попытки переподключения есть?

Dead peer detection виндой не поддерживается.

В смысле, венда не умеет отвечать на DPDшные «R_U_THERE»? Но по идее даже это не должно мешать свану принимать решения о реконнекте.

В общем, я бы уменьшил dpddelay и dpdtimeout и попробовал бы покурить, что pluto вывалит в control log. Хоть там и изрядный мозголомный адъ, конечно.

А если генерить трафик между концами, то тоннель (при нормальной работе канала связи) не рвется?

Оставлял минут на 20. Все еще пингалось.

В смысле, венда не умеет отвечать на DPDшные «R_U_THERE»?

Вот что говорит плуто :

pluto[5180]: "winhost" #1: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
..........
pluto[5180]: "winhost" #2: STATE_QUICK_I2: sent QI2, IPsec SA established transport mode {ESP=>0x5dfe1992 <0x4cf68e98 xfrm=3DES_0-HMAC_SHA1 NATOA=none NATD=none DPD=none}

DPD=none

DPD стоят в конфиге :

dpdtimeout=120 dpddelay=30 dpdaction=restart_by_peer

Но никаких действий по ним не проводится

Поймал момент отвала. Отваливается конект спустя 7 минут. На виндовой стороне :

 1-19: 19:23:36:975:310 QM Deleted. Notify from driver: Src <winhost_ip> Dest <linux_nat_external_ip> InSPI 1576933778 OutSpi 1291226776  Tunnel 0 TunnelFilter 0
 1-19: 19:23:36:975:310 srcEncapPort=37905, dstEncapPort=9202
 1-19: 19:23:36:975:310 Leaving adjust_peer_list entry 05521F68 MMCount 0 QMCount 0
 1-19: 19:23:36:975:310 constructing ISAKMP Header
 1-19: 19:23:36:975:310 constructing HASH (null)
 1-19: 19:23:36:975:310 Construct QM Delete Spi 1576933778
 1-19: 19:23:36:975:310 constructing HASH (Notify/Delete)
 1-19: 19:23:36:975:310 Not setting retransmit to downlevel client. SA 05584908 Centry 00000000
 1-19: 19:23:36:975:310 
 1-19: 19:23:36:975:310 Sending: SA = 0x05584908 to <linux_nat_external_ip>:Type 1.61987
 1-19: 19:23:36:975:310 ISAKMP Header: (V1.0), len = 68
 1-19: 19:23:36:975:310   I-COOKIE 06dbb70f449bf408
 1-19: 19:23:36:975:310   R-COOKIE e6a4249857082bb1
 1-19: 19:23:36:975:310   exchange: ISAKMP Informational Exchange
 1-19: 19:23:36:975:310   flags: 1 ( encrypted )
 1-19: 19:23:36:975:310   next payload: HASH
 1-19: 19:23:36:975:310   message ID: 6e577156
 1-19: 19:23:36:975:310 Ports S:9411 D:23f2
 1-19: 19:23:36:975:310 PrivatePeerAddr 502a8c0
 1-19: 19:24:01:803:310 ClearFragList

У плуто :

Jan 19 19:23:40 guest pluto[5180]: |..
Jan 19 19:23:40 guest pluto[5180]: | *received 68 bytes from <winhost_ip>:4500 on eth0 (port=4500)
Jan 19 19:23:40 guest pluto[5180]: |   06 db b7 0f  44 9b f4 08  e6 a4 24 98  57 08 2b b1
Jan 19 19:23:40 guest pluto[5180]: |   08 10 05 01  6e 57 71 56  00 00 00 44  b4 31 f7 3f
Jan 19 19:23:40 guest pluto[5180]: |   71 42 6d 75  84 5b d9 8a  1c 33 f8 54  a0 69 a4 5c
Jan 19 19:23:40 guest pluto[5180]: |   6d 67 6b 1f  a9 2b 67 08  66 7d 85 02  42 e3 7f b4
Jan 19 19:23:40 guest pluto[5180]: |   f7 72 28 fa
Jan 19 19:23:40 guest pluto[5180]: | **parse ISAKMP Message:
Jan 19 19:23:40 guest pluto[5180]: |    initiator cookie:
Jan 19 19:23:40 guest pluto[5180]: |   06 db b7 0f  44 9b f4 08
Jan 19 19:23:40 guest pluto[5180]: |    responder cookie:
Jan 19 19:23:40 guest pluto[5180]: |   e6 a4 24 98  57 08 2b b1
Jan 19 19:23:40 guest pluto[5180]: |    next payload type: ISAKMP_NEXT_HASH
Jan 19 19:23:40 guest pluto[5180]: |    ISAKMP version: ISAKMP Version 1.0 (rfc2407)
Jan 19 19:23:40 guest pluto[5180]: |    exchange type: ISAKMP_XCHG_INFO
Jan 19 19:23:40 guest pluto[5180]: |    flags: ISAKMP_FLAG_ENCRYPTION
Jan 19 19:23:40 guest pluto[5180]: |    message ID:  6e 57 71 56
Jan 19 19:23:40 guest pluto[5180]: |    length: 68
Jan 19 19:23:40 guest pluto[5180]: |  processing version=1.0 packet with exchange type=ISAKMP_XCHG_INFO (5)
Jan 19 19:23:40 guest pluto[5180]: | ICOOKIE:  06 db b7 0f  44 9b f4 08
Jan 19 19:23:40 guest pluto[5180]: | RCOOKIE:  e6 a4 24 98  57 08 2b b1
Jan 19 19:23:40 guest pluto[5180]: | state hash entry 9
Jan 19 19:23:40 guest pluto[5180]: | peer and cookies match on #2, provided msgid 00000000 vs 58f25d7b/00000000
Jan 19 19:23:40 guest pluto[5180]: | p15 state object not found
Jan 19 19:23:40 guest pluto[5180]: | ICOOKIE:  06 db b7 0f  44 9b f4 08
Jan 19 19:23:40 guest pluto[5180]: | RCOOKIE:  00 00 00 00  00 00 00 00
Jan 19 19:23:40 guest pluto[5180]: | state hash entry 16
Jan 19 19:23:40 guest pluto[5180]: | v1 state object not found
Jan 19 19:23:40 guest pluto[5180]: packet from <winhost_ip>:4500: Informational Exchange is for an unknown (expired?) SA with MSGID:0x5671576e
Jan 19 19:23:40 guest pluto[5180]: | - unknown SA's md->hdr.isa_icookie:
Jan 19 19:23:40 guest pluto[5180]: |   06 db b7 0f  44 9b f4 08
Jan 19 19:23:40 guest pluto[5180]: | - unknown SA's md->hdr.isa_rcookie:
Jan 19 19:23:40 guest pluto[5180]: |   e6 a4 24 98  57 08 2b b1
Jan 19 19:23:40 guest pluto[5180]: | * processed 0 messages from cryptographic helpers.
Jan 19 19:23:40 guest pluto[5180]: | next event EVENT_NAT_T_KEEPALIVE in 2 seconds
Jan 19 19:23:40 guest pluto[5180]: | next event EVENT_NAT_T_KEEPALIVE in 2 seconds

«parsing» зря добавил в выхлоп, сложно курить.
Интересно, если включить lcp ping на клиентcком ppp, решит ли это хотя бы проблему сброса неактивных соединений.
А вообще выходит как-то паршиво. Кто, кстати, рулит вендосервером?

включить lcp ping

Нет никакого L2TP. Это не VPN и не туннель. Это ipsec в транспортном режиме. Гонится как ESP через инет.

А вообще выходит как-то паршиво. Кто, кстати, рулит вендосервером?

Все под моим управлением.

Это ipsec в транспортном режиме.

Вон оно как.
Я уже как-то привык, что раз транспортный режим, то значит это roadwarrior с L2tp. Плюс фраза про «С windows клиентов все работает хорошо» меня ввела в заблуждение.
А напиши версии софта (венда, TMG (или что там?), дистрибутив линукса, версия ядра и версия свана, используемый стек (netkey?)) и топологию сети между шлюзами, я попробую на виртуалках смоделировать ситуацию. Любопытно же.

Для проприетарной системы делал связку Linux Racoon + Win. Работало нормально вроде. В Win XP и младше нет AES - пришлось 3DES.

А да, использовали PSK.

Конфиги не могу показать.

А напиши версии софта (венда, TMG (или что там?), дистрибутив линукса, версия ядра и версия свана, используемый стек (netkey?))

Венда 2003 server x86 с последними обновлениями. Ubuntu 12.04.03 x86 с последними обновлениями. openswan 2.6.37-1 Internet Key Exchange daemon Стек netkey

Топология такая :

ubuntu 192.168.2.5 -> NAT на Windows 2012 R2 RRAS -> inet -> server_2003. У server 2003 внешний IP. А задача такая, чтобы все клиенты за NAT могли обращаться к этому внешнему серверу 2003 по внешнему IP прозрачно и зашифрованно. Нет необходимости пробрасывать VPN со своей адресацией. В виндовых клиентах я завожу сертификат хоста, подписанный моим приватным CA и ставлю ipsec политику на адрес 2003 сервера с требованием security. И все пашет. microsoft микрософту не враг. Умеют они распознавать все ситуации как надо и переподключаться совершенно прозрачно.

Для проприетарной системы делал связку Linux Racoon + Win. Работало нормально вроде. В Win XP и младше нет AES - пришлось

3DES.

У меня бы тоже ракун заработал бы, если бы не NAT. Он на NAT спотыкается, есть несовместимости с микрософтовой имплементацией nat traversal

Неожиданно.
А убунта и сван здесь вообще для чего? Почему не связать венду с вендой?

Почему не связать венду с вендой?

Потому что в 1 месте стоит именно винда, в другом linux. Это не корпоратив, это скорее домашне-полурабочий сценарий. Где-то хочется иметь винду, а где-то Linux. Надо обеспечить безопасную связь между моими точками присутствия и общением в закрытой группе людей, без обязательной необходимости в центральном VPN сервере. Некоторые приложения поддерживают шифрование на уровне L7, у некоторых с этим проблема. Большинство приложений доверяет сертификатам, выпущенным стандартными CA, а хочется, чтобы работа была возможна только по удостоверению личной CA.

Да, кстати не сказал, что такой вариант сделать нельзя, чтобы виндовый шлюз прозрачно расшифровывал ipsec и направлял его внутрь в незашифрованном виде. Нет для этого средств. Разумеется, сам виндовый шлюз подключается через ipsec, но это не значит, что автоматически шифруется и проходящий трафик. Если надо, чтобы шлюз все делал, остается только туннель поднимать и включать маршрутизацию туннельных подсетей

Вот уж пояснил так пояснил.
1) В топике четко написано «есть винсервер за NAT». В каменте с топологией уже написано «У server 2003 внешний IP», а NAT куда-то подевался.
2) В каменте с топологией написано «без обязательной необходимости в центральном VPN сервере». При этом у тебя УЖЕ ЕСТЬ выделенный сервер с вин2003.

То есть, ты обыкновенный, хрестоматийный roadwarrior, но почему-то не хочешь себя им признавать. Что мешает разрешить L2TP на 2003й венде и ходить как все люди?

В топике четко написано «есть винсервер за NAT».

Да, наверно не так выразился. Я смотрел со стороны внутренней сети, и внешней сервер действительно за NAT.

В каменте с топологией написано «без обязательной необходимости в центральном VPN сервере». При этом у тебя УЖЕ ЕСТЬ выделенный сервер с вин2003.

Он не один. Есть еще парочка компов на внешнем IP, и не хотелось бы завязывать их функционирование на какой-то 1 комп. К тому же не хочется, чтобы кое-кто напрягался подключением к VPN. У него там болтается сип клиент на этот самый приватный сервер, и прописан он в автостарте. А комп - это ноут, работает он по вайфаю, при закрытии крышки идет в гибернацию. Поставит на VPN соединение «подключаться автоматически» я конечно могу, но сработает ли, не вылезет ли неприятное окошко. Зачем мне девушке объяснять что оно значит ? Когда ipsec, то все совершенно прозрачно, не надо никуда подключаться. Есть private.server.bananos.com, на него настраиваются все клиенты, есть инет - есть сип и жаббер, нет инета - все ясно, надо к нему подключиться. От впн только геморой.

То есть, ты обыкновенный, хрестоматийный roadwarrior, но почему-то не хочешь себя им признавать. Что мешает разрешить L2TP на 2003й венде и ходить как все люди?

Возможно как-то на 2003 винду ходить через L2TP без организации VPN ?

Ага, понял.
А проблема, стало быть, сводится к тому, что линуксовому клиенту в этом радостном мире неуютно по причине 1) непонятных обрывов по неактивности, 2) нерабочей PFS и 3) неспособности восстановить связь после обрыва.
Любопытно.
Если таки осилю в тестовой среде что-то подобное, отпишусь.

Возможно как-то на 2003 винду ходить через L2TP без организации VPN ?

Нет, вроде бы.

А проблема, стало быть, сводится к тому, что линуксовому клиенту в этом радостном мире неуютно

Да

по причине 1) непонятных обрывов по неактивности,

Причина понятна и логична. Нельзя быть уверенным жив ли клиент, если от него долго нет вестей. Поэтому винда рубит SA. Непонятно почему она не поддерживает DPD (ну ладно, бог с ней, оставим на совести Билли), и непонятно, почему openswan не может нормально обработать сообщение винды, что она обрывает SA. Openswan считает это сообщение не удовлетворяющим критериям проверки и игнорирует, продолжает считать SA активным, продолжает слать NA keep-alives, хотя уже все давно труп.

2) нерабочей PFS

Это не самое плохое. Подумал на досуге и вроде как я не совсем прав оказался. Обмен сессионными ключами идет по хелману, а сертификаты используются для удостоверения, чтобы чел-посередине не вклинился. Следовательно, ключ сессии в любом случае не дерайвится напрямую от ключевых пар хостов. Хотел бы этот вопрос еще уточнить.

3) неспособности восстановить связь после обрыва.

Ага, каждый раз приходится его ручками пинать на linux-е, чтобы ожил

Конфигов нет, но у самого недавно была похожая проблема, смотрите на пункт обход НАТ, там на линухах должен быть NAT-T, у меня только так все завелось

должен быть NAT-T

Включен траверсал.

config setup
<------>dumpdir=/var/run/pluto/
<------>nat_traversal=yes
<------>oe=off
<------>protostack=auto
<------>interfaces=%defaultroute
<------>#klipsdebug=all
<------>#plutodebug=all
<------>force_keepalive=yes
<------>keep_alive=20

conn bananos
    type=transport
    left=192.168.2.5
    leftcert=server.cert
    leftid=%fromcert
    right=private.server.bananos.com
    rightid=CN=private.server.bananos.com
    authby=rsasig
    ike=3des-sha1;modp2048
    pfs=no
    auth=esp
    dpdtimeout=120
    dpddelay=30
    dpdaction=restart_by_peer
    auto=start

Вот это на стороне винды тоже не помогает

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent AssumeUDPEncapsulationContextOnSendRule = 2

Это типа включает поддержку NAT-T на винде