gaaronk

Они НЕ МОГУТ быть не совместимыми между собой. Потому что настроены туннели с IKEv2, а "Сервер IPsec Virtual IP" использует IKEv1 Для IKEv2 и IKEv1 МОЖНО использовать РАЗНЫЕ proposal (шифрование, хэш, DH). Это просто разработчики криво реализовали логику. Хотя их понять можно, скажем для удаленного доступа используют aes128-sha1-dh14, а для туннеля 3des-md5-dh1, оба IKEv1 И при попытке поднять удаленное подключение с того IP с которого же устанавливается туннель естественно огребем NO_PROPOSAL_CHOSEN. Вот они и перестраховались, но перетянули гайки видимо, не делая различий между IKEv2 и IKEv1. Я бы при активации удаленного доступа и при создании туннелей версии IKEv1 просто бы делал в настройках туннелей не активными те proposal, которые на активированы в удаленном доступе. А cli не ограничивал - если человек лезет в CLI, он понимает что делает. Или бы использовал универсальную настройку для IKE. Вот такую: aes128-sha1-modp1024,aes256-sha256-modp1024,aes128-sha256-modp1024,aes256-sha256-modp2048,aes128-sha256-modp2048! В начале идут группы с modp1024 ибо винда 7ка по умолчанию не умеет modp2048, и при reauth если его инициирует сервер и в первой предложенной группе будет не modp1024 винда дропнет коннект. (Ну или править реестр add a DWORD HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\NegotiateDH2048_AES256 "1") aes128-sha1-modp1024 - единственный более менее приемлемый вариант для iOS младше 9ки.

Для справедливости скажу что после перехода на 2.09.A.7.0-0 то пропадание wi-fi 5GHz про которое я писал постом ранее было единственным за 2е суток.

Переход на версию 2.09.A.7.0-0 не помог. Apr 30 05:12:04 wmond WifiMaster1/AccessPoint0: (MT76x2) STA(78:31:c1:bf:e7:e2) had been aged-out and disassociated. Клиенты отваливаются на 5-10 секунд

Giga III, v2.08(AAUW.0)C2 На 5GHz had been aged-out and disassociated появляются тем чаще чем больше качаешь по воздуху. Один раз в 2-3 минуты. Self-test ниже.

Для AES еще используется ESP Pad, идущий после данных перед ESP Trailer. Например расклад для данных размером в 1400 в туннельном режиме AES, SHA-1 PACKET DETAILS Field Bytes New IPv4 Header (Tunnel Mode) 20 SPI (ESP Header) 4 Sequence (ESP Header) 4 ESP-AES (IV) 16 Original Data Packet 1400 ESP Pad (ESP-AES) 6 Pad length (ESP Trailer) 1 Next Header (ESP Trailer) 1 ESP-SHA-HMAC ICV (ESP Trailer) 12 Total IPSec Packet Size 1464 AES, SHA-256 PACKET DETAILS Field Bytes New IPv4 Header (Tunnel Mode) 20 SPI (ESP Header) 4 Sequence (ESP Header) 4 ESP-AES (IV) 16 Original Data Packet 1400 ESP Pad (ESP-AES) 6 Pad length (ESP Trailer) 1 Next Header (ESP Trailer) 1 ESP-SHA-256-HMAC ICV (ESP Trailer) 16 Total IPSec Packet Size 1468 AES, SHA-1, NAT-T, 1420 payload PACKET DETAILS Field Bytes New IPv4 Header (Tunnel Mode) 20 UDP Header (NAT-T) 8 SPI (ESP Header) 4 Sequence (ESP Header) 4 ESP-AES (IV) 16 Original Data Packet 1420 ESP Pad (ESP-AES) 2 Pad length (ESP Trailer) 1 Next Header (ESP Trailer) 1 ESP-SHA-HMAC ICV (ESP Trailer) 12 Total IPSec Packet Size 1488 Если есть CCO, то вот отличный калькулятор

Ну без обрывов при реаутентификации.

Мечта яблочников решается и на psk с использованием xauth-noauth для IKEv1 C сертификатами для клиентов есть нюансы. Стронгсван проверяет соответствие полученного от клиента ID клиентскому сертификату. Для MacOS и iOS - к сожалению использовать DN в качестве ID на клиенте нельзя, это баг клиента. Можно использовать как ID email или FQDN, соотвественно надо в сертификат надо добавлять соотвествующий SAN - fqdn или email Windows если использовать машинный сертификат использует авторизацию pubkey (в терминах стронгсвана) и корректно передает DN как ID. Но если использовать пользовательский сертификат, то используется eap-tls и тут винда как ID передает только значение поля CN, потому все то что записано в CN должно в сертификате дублироваться в SAN (fqdn или email) Ну и не забываем про EKU Client Authentication ( 1.3.6.1.5.5.7.3.2 ) IPSEC End System ( 1.3.6.1.5.5.7.3.5 ) IPSEC User ( 1.3.6.1.5.5.7.3.7 ) Если интересно кому могу отдельно рассказать так же весь ад с ciphers, lifiteme и прочими reauth По freeradius - если использовать только eap-tls или eap-mschapv2 то он не нужен. Но если мы хотим два разных соединения оба с MSCHAPv2 и в зависимости от eap_identity выдавать например разные сетки то начинается боль печаль с windows. Она не отдает eap_id пока ее явно не спросят. Соотвественно надо задавать eap_identity=%identity и прикручивать радиус. Двух соединений с просто с eap_identity=petrov и eap_identity=ivanov не получится. Но freeradius легковесен, для IPSec у меня используется в продакшене для EAP-TLS и EAP-MASCAHPv2 с минимальным конфигом. Хотя и тут не без костылей (хехе). Если пользователей мало то их можно хранить прямо в users файле, но любое его изменение приводит к тому что freeradius надо рестартовать. Если юзеров много нужен уже SQL или LDAP. Как то так.

Я думаю можно, если в CLI поправить ACL руками вписав вместо сети 192.168.1.0/24 что то вроде 192.168.0.0/22 И поставив галку NAT что бы не мудрить с вторым тоннелем (заворачивая в него пул динамики с первого рутера)

Впишите локальный адрес кинетика А можно показать вывод команды show ipsec (из телнета) в момент когда iphone подключен

Проверить наличие галки NAT в свойствах VPN сервера, и DNS тоже по идее надо бы указать Ну и проверяете вы не изнутри сети то хоть?

Даешь IKEv2 с авторизацией по сертификатам!

Ну если селектор будет 0.0.0.0/0.0.0.0 то по идее будет и интернет и "туннель" (думаю под этим вы имели ввиду доступ в локалку) Основной туннель не отвалится.

Ну если в настройках IPsec Virtual IP server выбрать не сеть конкретную, а Internet то как раз в инет айфон будет ходить через vpn (недолго правда, один час).

Конечно будут работать одновременно и IKEv1 и IKEv2

Можно скриптом /opt/etc/ndm/netfilter.d/02_nat.sh #!/bin/sh [ "$table" != "nat" ] && exit 0 /opt/sbin/iptables -t nat -A _NDM_IPSEC_POSTROUTING_NAT -o ngre+ -j ACCEPT /opt/bin/logger -t "iptables" "Add GRE rules to table $table" Только имя -o <интерфейс> задайте нужное вам

Ну меня слишком много, но все же psk_authenticator.c строка 73 if (key != NULL) { DBG1(DBG_IKE, "found linked key for crypto map '%s'", ike_sa_name); } else Разве не надо перед выводом дебага сделать что то вроде my_id = this->ike_sa->get_my_id(this->ike_sa); Что бы потом использовать my_id при вызове (строка 91) if (!keymat->get_psk_sig(keymat, FALSE, this->ike_sa_init, this->nonce, key->get_key(key), my_id, this->reserved, &auth_data)) А то получается что если мы нашли linked key то my_id не определяется. Если все это бред, то удалите топик пожалуйста.

Разобрался где косяк (?) Итак крипто профайл вида crypto ipsec profile remote.domain.com dpd-interval 20 identity-local fqdn local.domain.com match-identity-remote fqdn remote.domain.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy preshared-key ns3 <PSK> Мы иницируем установку туннеля. В момент IKE сессии передаем свое ID как local.domain.com но, начинаем вычислять на своей стороне MAC с использованием ID remote.domain.com Mar 22 23:03:10ipsec11[IKE] IKE_CERT_PRE task Mar 22 23:03:10ipsec11[IKE] IKE_AUTH task Mar 22 23:03:10ipsec11[IKE] found linked key for crypto map 'test-tunnel' Mar 22 23:03:10ipsec11[IKE] IDx' => 22 bytes @ 0x75ef5ba0 Mar 22 23:03:10ipsec11[IKE] 0: 02 00 00 00 XX XX XX XX XX XX XX XX XX XX XX XX ....remote.domain Mar 22 23:03:10ipsec11[IKE] 16: 2E 63 6F 6D .com Mar 22 23:03:10ipsec11[IKE] SK_p => 32 bytes @ 0x471ef8 Mar 22 23:03:10ipsec11[IKE] 0: A2 DA A4 C6 E6 65 84 DD A6 CC CF 2E 5F 3D 36 DF .....e......_=6. Mar 22 23:03:10ipsec11[IKE] 16: 89 D5 05 F3 94 A0 A9 20 36 C7 75 5F 98 F1 97 D9 ....... 6.u_.... Mar 22 23:03:10ipsec11[IKE] octets = message + nonce + prf(Sk_px, IDx') => 528 bytes @ 0x471418 Mar 22 23:03:10ipsec11[IKE] 0: BD ED 37 4A 8B D9 5A 22 00 00 00 00 00 00 00 00 ..7J..Z"........ Что приводит к Mar 22 23:03:12ipsec 15[IKE] received AUTHENTICATION_FAILED notify error Если мы из профайла уберем preshared-key и опишем его как crypto ike key test-key ns3 <PSK> fqdn remote.domain.com То все хорошо. Мы передаем свое ID как local.domain.com и начинаем вычислять на своей стороне MAC с использованием ID local.domain.com Mar 22 23:17:50ipsec03[IKE] IKE_AUTH task Mar 22 23:17:50ipsec03[IKE] linked key for crypto map 'test-tunnel' is not found, still searching Mar 22 23:17:50ipsec03[IKE] authentication of 'local.domain.com' (myself) with pre-shared key Mar 22 23:17:50ipsec03[IKE] IDx' => 21 bytes @ 0x76becba0 Mar 22 23:17:50ipsec03[IKE] 0: 02 00 00 00 XX XX XX XX XX XX XX XX XX XX XX XX ....local.domain Mar 22 23:17:50ipsec03[IKE] 16: 2E 63 6F 6D .com Mar 22 23:17:50ipsec03[IKE] SK_p => 32 bytes @ 0x8113c0 Mar 22 23:17:50ipsec03[IKE] 0: 96 2E 4D 0C 3F D8 D8 FA 95 D8 22 7C 6C 80 73 98 ..M.?....."|l.s. Mar 22 23:17:50ipsec03[IKE] 16: AD E5 2B 56 F4 46 B0 22 D3 EE 1E 88 A8 11 E1 79 ..+V.F.".......y Mar 22 23:17:50ipsec03[IKE] octets = message + nonce + prf(Sk_px, IDx') => 528 bytes @ 0x813140 В итоге Mar 22 23:17:57ipsec 06[IKE] authentication of 'remote.domain.com' with pre-shared key successful

Зарулить можно. Только надо на каждом spoke (луче) описать выделение трафика для засовывание в ipsec как <local network> - <сеть центельного узла> <local network> - <сеть spoke2> <local network> - <сеть spoke3> и тд. Что не очень удобно, но работает. Кинетик же из списка доступа читает только первую строчку. По этому обычно делают туннели и внутри них гоняют маршруты. Сделайте full-mesh - туннель между 4G и "второй ультрой" С выделением трафика 192.168.13.128/25 - 192.168.10.0/24

Просто в моей специфической ситуации все мои SIP пиры принимают только G729. Сейчас для телефонии стоит SPA3102, в нее воткнута DECT база. Хотелось бы SPA задействовать под другие задачи и убрать лишнее преобразование аналог-цифрв. Если самим модулем не поддерживается то проще наверное поднять астериск из entware, зарегистрировать модуль на нем и делать рекодинг астериском.

Скажите, а модуль DECT поддерживает кодек G729 ?

Не могу найти информацию. Модуль Keenetic Plus DECT поддерживает кодек g729 ?

Голым IPSec это получится, но не на кинетике, где для селектора трафика можно использовать только один элемент ACL. Можно на средней ультре делать двусторонний NAT, что бы клиент лез к адресам из диапазона 192.168.13.0/128, а его натило в src из сети192.168.13.0/128 dst 192.168.10.230 Ну и virce versa.

Поясню немного свою позицию. NAT не является средством контроля и безопасности. Использовать его для этого - опасно. Это всего лишь правила по которым меняются source и/или destination адреса/порты у пакетов в зависимости от кого/кому предназначен пакет, через какой интерфейс он входит/выходит. Контролировать доступ, кто куда может ходить, по каким портам и адресам - надо в filter. Если пакет предназначен адресу вашего рутера он обработается в цепочке INPUT, если он транзитный то в FORWARD. Вот там и контролируйте. По умолчанию в кинетике пакет нового соединения не будет маршрутизироваться если он пришел из public интерфейса, то есть ваш рутер при нескольких провайдерах не будет транзитным. Транзит разрешен от private - ко всем и и от protected к public

Нет конечно. Раз прилетает на IP рутера, то в FORWARD оно не попадет и НЕ будет маршрутизироваться. Рутер ответит скорее всего icmp unreachable.

Если такой пакет прилетит от ISP то его срежет фильтр.