[M-a-x-Z]

Добрый день!

 

Имеется Cisco ASR 1001X, на котором настроены подключения абонентов по VPN (L2TP):

...
aaa new-model
!
!
aaa group server radius FOR_VPDN
 server-private 10.10.10.1 key test
 server-private 10.10.10.2 key test
 ip radius source-interface TenGigabitEthernet0/0/1.52
!
aaa authentication ppp default group FOR_VPDN
...
vpdn enable
vpdn logging
no vpdn logging cause normal
!
vpdn-group VPN
 ! Default L2TP VPDN group
 description l2tp group
 accept-dialin
  protocol l2tp
  virtual-template 1
 no l2tp tunnel authentication
!
...
interface Loopback1
 ip address 10.200.0.1 255.255.255.255
...
interface Virtual-Template1
 ip unnumbered Loopback1
 no ip redirects
 ip nat inside
 ip tcp adjust-mss 1360
 peer default ip address pool ppp_pool
 no snmp trap link-status
 ppp max-bad-auth 20
 ppp authentication ms-chap-v2
!
ip local pool ppp_pool 10.200.0.2 10.200.255.254
...

Всё прекрасно работает в Windows 10 - достаточно создать VPN соединение с параметрами по-умолчанию и подключение будет устанавливаться.

При этом если поставить обязательное шифрование - всё будет работать и если поставить запрет без шифрования - всё тоже будет работать.

Но в Windows 7 вылазит ошибка 766 "Не удалось найти сертификат. Подключениям, которые используют этот L2TP-протокол через IPSec, требуется установка на компьютере сертификата компьютера". Если при этом на вкладке "безопасность" указать, что подключения без шифрования разрешены - всё начинает работать, хотя сервер mppe обеспечивает и, повторюсь, W10 всё ОК.

 

Меня интересует вопрос - как настроить Cisco таким образом, чтобы в Windows 7 срабатывало подключение с настройками по умолчанию - т.е. не надо было пользователю залазить в глубь свойств подключения и ставить галочку.

 

 

 

 

[Ivan_83]

Думается никак.

Для венды был регфайл отключающий IPSEC для L2TP.

Видимо новая венда поумнела, а старую МС вряд ли станет.

[M-a-x-Z]

Я бы даже готов был настроить шифрование, как она хочет, но там тогда, кажется, еще больше гемора будет с настройками у клинета.

 

Может можно решить проблему подписав ASR каким-нибудь геотрастовским ключем, или ошибка 766 не об этом?

[Ivan_83]

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

[ShyLion]

23 часа назад, M-a-x-Z сказал:

Я бы даже готов был настроить шифрование, как она хочет, но там тогда, кажется, еще больше гемора будет с настройками у клинета.

 

Может можно решить проблему подписав ASR каким-нибудь геотрастовским ключем, или ошибка 766 не об этом?

Делается простой PSK, и вбивается в настройках подключения.

 

[M-a-x-Z]

В 23.10.2017 в 09:40, ShyLion сказал:

Делается простой PSK, и вбивается в настройках подключения.

 

К сожалению это не решает ни одной проблемы

а) если указать PSK - пользователю всё-равно придётся настраивать свойства соединения вручную, автоматом его тогда не создать

б) шифрование тоже будет весьма сомительным, т.к. всем пользователям придётся делать одинаковый PSK.

Т.е. ни безопасности, ни удобства.

[Ivan_83]

http://netlab.dhis.org/wiki/ru:software:win:rras:conn_import_export

[ShyLion]

12 часов назад, M-a-x-Z сказал:

К сожалению это не решает ни одной проблемы

а) если указать PSK - пользователю всё-равно придётся настраивать свойства соединения вручную, автоматом его тогда не создать

б) шифрование тоже будет весьма сомительным, т.к. всем пользователям придётся делать одинаковый PSK.

Т.е. ни безопасности, ни удобства.

MPPE будет работать на уровне PPP.

Каким таким "автоматом" ? Умолчальные установки все равно как правило не устраивают. Мы, например, убираем галку дефолтного маршрута, чтобы устанавливался только классовый 10/8.

Есть четкая инструкция простая, все ее выполняют и у всех все работает.

 

[M-a-x-Z]

В 25.10.2017 в 09:00, ShyLion сказал:

MPPE будет работать на уровне PPP.

Каким таким "автоматом" ? Умолчальные установки все равно как правило не устраивают. Мы, например, убираем галку дефолтного маршрута, чтобы устанавливался только классовый 10/8.

Есть четкая инструкция простая, все ее выполняют и у всех все работает.

 

Ну да, видимо совсем без инструкции не удастся. Жаль. С PPTP такое легко канает, но его не поддерживает ASR ((

 

Кстати, с MPPE тоже выползла проблема. Если в натсройках Virtual-interface 1 указать ppp encryption mppe auto, то перестаёт цепляться и W10 и W7. Хотя та же W10 прекрасно цеплялась с MPPE128, когда стороны сами согласовывали параметры и это не было явно указано ((.

[ShyLion]

PPTP очень непредсказуемо работает в мобильных сетях и через прочие НАТы, то что его отовсюду потихоньку выпиливают считаю за благо.

 

У нас на корпоративный доступ такой тимплейт:

 

interface Virtual-Template1
 description PPP template
 mtu 1300
 ip unnumbered Loopback0
 no ip redirects
 ip flow ingress
 ip flow egress
 zone-member security z_PPP
 ip tcp adjust-mss 1260
 load-interval 30
 peer default ip address pool pool_general
 no snmp trap link-status
 no keepalive
 ppp encrypt mppe 128
 ppp authentication ms-chap-v2 callin VPN
 ppp authorization VPN
 ppp accounting VPN
 ppp ipcp dns 10.x.x.x
 ppp link reorders
 ppp timeout retry 10

Полсотни работников работают без проблем со всевозможных платформ. Радиус виндовый.

Отдельным пользователям радиус меняет зону - меняется и доступ в сеть.

[M-a-x-Z]

В 27.10.2017 в 13:33, ShyLion сказал:

PPTP очень непредсказуемо работает в мобильных сетях и через прочие НАТы, то что его отовсюду потихоньку выпиливают считаю за благо.

 

У нас на корпоративный доступ такой тимплейт:

 

interface Virtual-Template1
 description PPP template
 mtu 1300
 ip unnumbered Loopback0
 no ip redirects
 ip flow ingress
 ip flow egress
 zone-member security z_PPP
 ip tcp adjust-mss 1260
 load-interval 30
 peer default ip address pool pool_general
 no snmp trap link-status
 no keepalive
 ppp encrypt mppe 128
 ppp authentication ms-chap-v2 callin VPN
 ppp authorization VPN
 ppp accounting VPN
 ppp ipcp dns 10.x.x.x
 ppp link reorders
 ppp timeout retry 10

Полсотни работников работают без проблем со всевозможных платформ. Радиус виндовый.

Отдельным пользователям радиус меняет зону - меняется и доступ в сеть.

У меня PPTP удалённое подключение к офису через андроид и LTE - полёт нормальны. Хотя вопрос не в этом.

 

А можно увидеть конфигурацию AAA листа VPN?

 

IPSec вы при этом используете? Или:

vpdn-group ...
....

    no l2tp tunnel authentication

?

 

 

Изменено 28 октября, 2017 пользователем M-a-x-Z

[ShyLion]

В 10/28/2017 в 23:04, M-a-x-Z сказал:

IPSec вы при этом используете? Или:

 

Не "или", а "и". При этом L2TP работает и без IPSec, если клиент не просит.

 

aaa new-model
!
aaa authentication login VPN group LAN_RADIUS
aaa authentication ppp VPN local group LAN_RADIUS
aaa authorization network VPN local group LAN_RADIUS
aaa accounting network VPN
 action-type start-stop
 group LAN_RADIUS
!
aaa group server radius LAN_RADIUS
 server-private x.x.x.x ...
 ip radius source-interface Loopback0
!
vpdn enable
vpdn logging
vpdn logging local
vpdn logging user
vpdn logging tunnel-drop
!
vpdn-group L2TP
 ! Default L2TP VPDN group
 description l2tp group
 accept-dialin
  protocol l2tp
  virtual-template 1
 no l2tp tunnel authentication
!
crypto keyring L2TP_IPSec
  pre-shared-key address 0.0.0.0 0.0.0.0 key WellKnownKey
no crypto isakmp default policy
!
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 2
!
crypto isakmp policy 20
 encr aes 256
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp policy 30
 encr 3des
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp policy 40
 encr aes
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp policy 50
 encr aes
 authentication pre-share
 group 2
!
crypto isakmp policy 60
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp policy 70
 encr 3des
 hash md5
 authentication pre-share
!
!
crypto ipsec transform-set 3DES_SHA_tr esp-3des esp-sha-hmac
 mode transport
crypto ipsec transform-set AES_SHA_tr esp-aes esp-sha-hmac
 mode transport
crypto ipsec transform-set AES_256_SHA_tr esp-aes 256 esp-sha-hmac
 mode transport
crypto ipsec transform-set aes256-sha1 esp-aes 256 esp-sha-hmac
 mode tunnel
!
!
crypto dynamic-map L2TP_IPSec 1
 set nat demux
 set transform-set 3DES_SHA_tr
crypto dynamic-map L2TP_IPSec 2
 set nat demux
 set transform-set AES_SHA_tr
crypto dynamic-map L2TP_IPSec 3
 set transform-set AES_256_SHA_tr
crypto dynamic-map L2TP_IPSec 4
 set transform-set 3DES_SHA_tr
crypto dynamic-map L2TP_IPSec 5
 set transform-set AES_SHA_tr
!
!
crypto map OUTSIDE local-address Loopback1
crypto map OUTSIDE 65535 ipsec-isakmp dynamic L2TP_IPSec
!
interface Virtual-Template1
 description PPP template
 mtu 1300
 ip unnumbered Loopback0
 no ip redirects
 ip flow ingress
 ip flow egress
 ip tcp adjust-mss 1260
 load-interval 30
 peer default ip address pool pool_general
 no snmp trap link-status
 no keepalive
 ppp encrypt mppe 128
 ppp authentication ms-chap-v2 callin VPN
 ppp authorization VPN
 ppp accounting VPN
 ppp ipcp dns 10.x.x.x
 ppp link reorders
 ppp timeout retry 10
!
interface GigabitEthernet0/0.609
 description Link to inet
 encapsulation dot1Q 609
 ip address 91....
 crypto map OUTSIDE
!
ip local pool pool_general 10.95.xx.1 10.95.xx.254
!

 

Некоторые крипто-полиси и трансформы не нужны, но я уже не помню какие к чему, роутер раньше еще другие криптотуннели имел. Исключи опытным путем.

 

Да, нюанс: роутер ISR2, 3954E. Но вроде на ASR в этом плане все также.

[M-a-x-Z]

В 30.10.2017 в 11:59, ShyLion сказал:

Не "или", а "и". При этом L2TP работает и без IPSec, если клиент не просит.

 

 

Некоторые крипто-полиси и трансформы не нужны, но я уже не помню какие к чему, роутер раньше еще другие криптотуннели имел. Исключи опытным путем.

 

Да, нюанс: роутер ISR2, 3954E. Но вроде на ASR в этом плане все также.

Спасибо большое!

 

Насчёт IPSec, в принципе, понятно (только не понятно, зачем он нужен).

Оказалось всё-таки дело в алгоритме винды 7. Она понимает "обязательное шифроавние" как обязательный IPSec и уже не важно, что там внутри PPP.

Поэтому оптимальной настройкой видится всё-таки ручная установка юзером параметра "необязательное шифрование" - после этого винда перестаёт докапываться до сретификатов или ключей (PSK юзать можно, но инструкция для юзеров получается сложнее). Надо ещё поковыряться, может быть удастся подписать сервер нормальным сертификатом и отказаться от ключей. Хотя пока это кажется излишним.

 

Но теперь упёрся в другую проблему. При указании шифрования mppe для ppp циска блажит:

 

ASR1001X#test virtual-Template 1 subinterface

Subinterfaces cannot be created using Virtual-Template1
Interface specific commands:
 ppp encrypt mppe auto

 

При этом

License Level: adventerprise
License Type: EvalRightToUse
Next reload license Level: adventerprise

 

При переключении на  advipservices та же беда.

 

Образ нормальный

System image file is "bootflash:asr1001x-universalk9.03.16.03.S.155-3.S3-ext.SPA.bin" - т.е. не NPE. Куда ещё можно посмотреть?

Гугл рекомендует сменить лицензию и убрать нпе. Но это уже сделано ((

 

 

 

Изменено 17 ноября, 2017 пользователем M-a-x-Z

[M-a-x-Z]

С mppe всё оказалось просто - ASR его не поддерживает в следствие отсутствия поддержки в нём PPTP и поддержки mppe в L2TP.

 

Вопрос: можно ли научить (а точнее поступать по умолчанию) клиента опознавать сервер по сертификату GeoTrust, а сервер -принимать от клиента любую дрянь в качестве сертификата.

 

 

 

[dr Tr0jan]

12 hours ago, M-a-x-Z said:

можно ли научить (а точнее поступать по умолчанию) клиента опознавать сервер по сертификату GeoTrust

Да, но это скорее фича не сервера VPN, а радиуса.

 

12 hours ago, M-a-x-Z said:

а сервер -принимать от клиента любую дрянь в качестве сертификата

В чём смысл?

[zhenya`]

имхо тут дело не в серте.. да и ipsec явно будет больнее для ASR.

[M-a-x-Z]

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

Да, но это скорее фича не сервера VPN, а радиуса.

 

В чём смысл?

Смысл сделать настройку L2TP для клиента такой же простой, как это раньше было для PPTP ((

 

Но видимо да - это процесс настройки не упростит.

 

Вот а что убили PPTP? Нормально работал на всех платформах, пока его специально банить не начали.

Не везде же топовая секьюрность требуется. Как средство простой идентификации клиента в сети доступа - хорошая вещь была (

[Ivan_83]

4 часа назад, M-a-x-Z сказал:

Вот а что убили PPTP? Нормально работал на всех платформах, пока его специально банить не начали.

Не везде же топовая секьюрность требуется. Как средство простой идентификации клиента в сети доступа - хорошая вещь была (

Потому что МС наговнокодила и ей все уже много лет тыкали что оно вообще не секурно, абсолютно бесполезная вещь.

Поскольку оно было для "виртуальных частных сетей" и не обеспечивало приватности ни разу то и выкинули.

То что пострадали в итоге всякие недопровайдеры которые этим пользовались никого не волнует, для провайдеров сделали PPPoE.

[ShyLion]

16 hours ago, M-a-x-Z said:

Вот а что убили PPTP? Нормально работал на всех платформах, пока его специально банить не начали.

Не везде же топовая секьюрность требуется. Как средство простой идентификации клиента в сети доступа - хорошая вещь была (

Ты суть работы протокола изучал? С ним такой-же гемор как и с фтп и со многими другими творениями до-фаервольного века. Он состоит из двух потоков, TCP и GRE. Чтобы нормально провести это все через фаерволы и НАТы нужно постараться, причем на всем пути. Тот-же L2TP тупо работает по одному UDP порту и при наличи постоянного простого кипалива в виде ppp-echo может нормально переживать НАТы и фаерволы. С IPsec тодже сперва начудили, но потом исправились, пустив ESP поверх UDP.

[M-a-x-Z]

36 минут назад, ShyLion сказал:

Ты суть работы протокола изучал? С ним такой-же гемор как и с фтп и со многими другими творениями до-фаервольного века. Он состоит из двух потоков, TCP и GRE. Чтобы нормально провести это все через фаерволы и НАТы нужно постараться, причем на всем пути. Тот-же L2TP тупо работает по одному UDP порту и при наличи постоянного простого кипалива в виде ppp-echo может нормально переживать НАТы и фаерволы. С IPsec тодже сперва начудили, но потом исправились, пустив ESP поверх UDP.

Да, про беспортовый GRE в курсе) Но я сужу по клиентской части - PPTP в этом плане лично мне геморроя не доставлял. Как-то всё нормально взлетало и заводилось. Хоть через 4Г, хоть Wi-Fi и т.д. Вот насчёт того, что точно знаю, как работало - не уверен.

 

С L2TP интереснее всё.

Ввиду отсутствия в нём минимального шифрования (хотя бы обеспечивающего защиту от дурака: не каждый сосед сходу вскроет MSCHAPv2 и mppe128. Да и внутри всё-равно будет HTTPS) теперь к нему надо прикручивать IPsec.

Но IPsec обеспечивает удостоверение ... рабочих станций, а не пользователей. Ему или сертификат или pre-shared подай (а это доп. настройки для юзера). Причём, если pre-shared не секретный (а в крупной сети он таким не будет), то у злоумышленника остаётся возможность прикинуться сервером. А если брать сертификаты, то надо ещё всех клиентов ими обеспечить (представь себе, что HTTPS требовал предварительного распределения клиентских сертификатов и проверял бы пользовательские ПК на валидность - мечта РКН).

 

В моём понимании идеальный VPN для пользователя должен работать как HTTPS, где сервер удостоверен публичным сертификатом, а валидность клиента не проверяется вообще. И будет проверена уже туннельным протоколом поверх стойкого шифра на одноразовых ключах. Т.к. как в контактике пользовтаель смотрит на зелёный значок и вводит пароль уже внутри тоннеля (plain-text).

Есть, конечно SSTP - но у него что-то грустно с поддержкой клиентами и пихать весь трафик мало того, что в TCP, да ещё и в HTTPS как-то избыточно.

 

Т.е. я правильно понимаю, что для IPSec нет реализации с односторонней поддержкой аутентификации только для сервера и априориным доверием клиенту (подобно SSL)?

 

 

 

 

 

 

13 часов назад, Ivan_83 сказал:

Потому что МС наговнокодила и ей все уже много лет тыкали что оно вообще не секурно, абсолютно бесполезная вещь.

Поскольку оно было для "виртуальных частных сетей" и не обеспечивало приватности ни разу то и выкинули.

То что пострадали в итоге всякие недопровайдеры которые этим пользовались никого не волнует, для провайдеров сделали PPPoE.

я, конечно, маркетингового исследования не проводил, но, по ощущениям, этих "недопровайдеров" существенно больше половины... Особенно среди "лидеров рынка".

 

А если говорить о идеальных сферических стандартах в вакууме с позиции чистой теории, то и PPPoE - дичь. 802.1х с динамическим назначением влана - вот в чём сила.

[dr Tr0jan]

4 hours ago, M-a-x-Z said:

В моём понимании идеальный VPN для пользователя должен работать как HTTPS, где сервер удостоверен публичным сертификатом, а валидность клиента не проверяется вообще.

Я неспроста спросил, в чём смысл этого явления? По определению VPN - это private network, а не public service (как HTTPS), т.е. валидность клиента проверяется по определению.

Какую цель вы преследуете? Если действительно VPN, то можете использовать SSL VPN (фактически шифрованный туннель, "как HTTPS"). Если вы провайдер интернета, то для вас существует PPPoE, и никакая это не дичь. Сомневаюсь, что вам нужен 802.1x (ибо авторизировать, в вашем случае, клиента всё же необходимо).

Изменено 12 марта, 2018 пользователем dr Tr0jan

[DRiVen]

31 минуту назад, M-a-x-Z сказал:

я, конечно, маркетингового исследования не проводил, но, по ощущениям, этих "недопровайдеров" существенно больше половины... Особенно среди "лидеров рынка"

Какое тут исследование, вы вообще на используемые "лидерами рынка" на доступе протоколы давно смотрели? Откуда дрова насчет "больше половины"? Все, кто когда-то сидел на L2TP, давно переехали на РРРоЕ (а насчет PPTP вообще не слышал,чтобы кто-то из крупняка на нем доступ делал). Возможно где-то на небольших сегментах осталось, но это исключение.

[ShyLion]

43 minutes ago, M-a-x-Z said:

Т.е. я правильно понимаю, что для IPSec нет реализации с односторонней поддержкой аутентификации только для сервера и априориным доверием клиенту (подобно SSL)?

В IPSec, а ныне более модный IKEv2 хренова гора всяких возможностей на любой вкус и цвет, но тут проблема не в стандарте а в том, на сколько его реализуют конкретные производители операционок и железа.

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

А мы просто заложники в этой ситуации и вынуждены под всех подстраиваться и искать варианты.

 

ЗЫ: а что, L2TP не уммет MPPE? MPPE же поверх PPP работает, что мешает его использовать? Тут главное поддержка MS-CHAPv2 между NAS и AAA.

[M-a-x-Z]

4 минуты назад, ShyLion сказал:

ЗЫ: а что, L2TP не умеет MPPE? MPPE же поверх PPP работает, что мешает его использовать? Тут главное поддержка MS-CHAPv2 между NAS и AAA.

Я тоже так думал.

Нет не поддерживается. Дважды. Первый раз майкрософтом (типа хотите шифроать - поднимайте поверх IPsec, а mppe несекурно) и второй раз, чтобы добить, Cisco. На ASR строка про mppe делает Virtual-Template невалидным сразу. А на ISR (как у вас в конфиге) она вводится, но игнорируется применительно к L2TP.

С MSCHAPv2 - проблем нет))

Изменено 12 марта, 2018 пользователем M-a-x-Z

[ShyLion]

И правда.

 

 

1 hour ago, M-a-x-Z said:

Есть, конечно SSTP - но у него что-то грустно с поддержкой клиентами и пихать весь трафик мало того, что в TCP, да ещё и в HTTPS как-то избыточно.

 

Почему HTTPS? Просто SSL/TLS. Просто номер порта выбран 443, чтобы через фаерволы проще вылазить (меньше галочек для недо-админов).

Только вот циска лицензию не купила.