Приветствую, форумчане !
Столкнулся с такой бедой, по ходу реализации некоего масштабного проекта
необходимо на dfl (задействованы 260E/860E и большая часть 1660) поднять,
на каждой PPTP, L2TP over IPsec, GRE и SSL VPN сервера/туннели.
Отрабатываем пока на 260E (начали с прошивки 2.40 перешли на 2.60).
Из перечисленного пока как надо не заработало ничего )) но беспокоит пока
больше всего L2TP over IPsec сервер.

Суть задачи в некой распределенной локальной сети необходимо соединить часть
оборудования по PPTP часть по L2TP (и т.д.) и обеспечить подключение к оборудованию
"из вне".
Организовал на dfl260 на wan порте l2tp сервер. Делаю все по мануалу, соединение
в экспериментальной локальной (т.е. и сервер и клиент в одной сети к примеру 192.168.1.0/24)
все четко заработало, но как стал тестировать с соединениями "из вне" - болт.
Ни одного коннекта не прошло, как "не вертел" настройками. Соединение останавливается
обрывается при работе фаз IKE.
Как к внешнему миру подключен dfl:
Схема по сути каноническая dfl стоит за Cisco ASA которая подключена к провайдеру,
на ней висит несколько белых IP, один из них методом статического NAT (вариант SAT)
пробрасывается на wan порт dfl. Еще раз замечу преобразование адресов происходит "чисто"
один к одному, соответственно порты также транслируются один в один. По крайней мере так
утверждает наш специалист по Cisco, который отвечает за настройку ASA.))
В качестве клиентов - L2TP клиенты win 8.1

Собственно вопрос: может есть какая то информация о проблемах соединения
dfl с прошивкой 2.40 и клиентами на Win 8.1 ?

Мануал и 2.40 и 2.60 на эту тему прочитан до дыр уже не знаю куда смотреть.

PS: для прояснения ситуации попробовал найти другой не родной клиент L2TP
с целью понять это проблема с клиентом Win 8.1 или нет. Как такового аналога не
нашел, но поставил и протестил такую штуку как Shrew.
Результат (разумеется поправил настройки на режим туннеля IPsec/IKE) при подключении
Shrew аналогичные ошибки, т.е. также коннекта не получилось.

PPS: для чистоты эксперимента пробовал включать/выключать NAT-T не помогло.
Есть еще нюанс внешнее соединение клиента выполняется из под LTE сети,
сделано специально, ттак как на объектах это единственное что есть. Пробовали соединиться
из под МТС, Мегафон. Также пробовали для чистоты эксперимента подключиться через
проводного провайдера результат один - коннект не проходит.

PPPS: на том же wan запущен и PPTP сам по себе сервер работает четко, вопросы к установлению
коннекта нет

Помогите люди добрые, бьюсь как рыба об лед )) а впереди еще столько всего....интересного

Ну про телепатов вспоминать не будем:))
Показывайте чего наваяли - скрины смотреть будем.
Выкладывайте логи с длинка - чего пишет в момент конекта?
А нельзя убрать циску вначале? какой смысл городить огород?
А по какому мануалу ксати делали?
У меня l2tp over ipsec работает на трех DFL - цепляются все, от андройда до win 8

Приветствую !
а я думал что о я один такой не телепатический ))
логи, сегодня будут, а вот что касается ASA, все верно
про огород, но он вынужденный, т.е там
где разворачивается стенд, есть только именно такая
схема с белым IP. Провайдер один и сеть с белыми IP
выделены именно на нее на ней много чего висит кроме стенда.
Причем не сильно пытаюсь с данным бороться в силу того
что у заказчика будет практически такая же схема при
коннекте внешних пользователей к системе.

Итак продолжениt эпопеи...
из за оочень сильно сжатых сроков было принято решение на этапе отработки
убрать Cisco/ASA из сетевой схемы, сейчас DFL пподключен на прямую к резервному
провайдеру и хоть и не сразу но заставить работать L2TP/IPsec удалось, в том числе пришлось
NAT-T активировать.
И тут началось следующая глава...
Еще раз немного о специфики поставленной задачи - необходимо подключить к "системе"
не только удаленных пользователей этой самой системы (находятся по заранее неизвестным
интранет/интеренет сетям), но и внутри самой системы, где организованы довольно много
локальных (с не пересекающимся адресным пространством) сетей - в несколько общих.
Т.е. имеем LocalNet_1, LocalNet_2...LocalNet_N и Internet.
Указанные сети (LocalNet) маршрутизируются и защищаются DFL, взаимодействие внутренних
и внешних сетей на них, взаимодействие между такими сегментами разбросанными по
месторождению запланировано посредством GRE туннелями, но это пока перспективная головная
боль.
Помимо этого часть серверов и АРМ-в должна объединиться в "третий" класс сетей на основе
VPN. Есть требование - все клиенты конкретной сети VPN_X должны "прозрачно" видеть друг
друга.
Вот здесь и встала очередная загвоздка, а именно сервера VPN (L2TP, PPTP, SSL VPN) заработали
и в тестовом режиме правильно маршрутизируются с другими сетями, НО, не один клиент VPN
(всех типов) не видит свох "соседей" по сети. Более того практически не удается добиться
пингов клиентом даже адреса сервера.
Два дня "вращал" настройки и самих серверов и клиентов win, ничего путного не получилось.
Иногда клиент пингует адрес своего сервера, НО при этом пингует только первый подключивщийся.
Клиенты подключившиеся следом не видят адреса сервера иногда нет и этого, определить логику
не получилось.
Что касается клиентов - все на ОС Win 8.1 или серверной 2012. Настройки "адаптеров"
VPN пересмотрел 50 раз, хотя там и настроек собственно нет. Установлено получать
адрес динамически, снят чек на параметре "использовать основной шлюз в удаленной сети".
Добавление маршрутов на основе классов снимал и ставил тоже не однократно не
помогло. Пробовал, после установления соединений прописывать статически маршруты.
Пример:
PPTP сервер имеет IP=192.168.120.254/24
соответственно добавлял статический маршрут вида:
192.168.120.0 mask 255.255.255.0 192.168.110.254 IF <номер интерфейса>
Ни на одном клиенте эффекта не дало. Для информации - на тестах клиенты выходят в инет через
разных провайдеров, соответственно DFL их видит с разными IP (это я к PPP-ALG может на на воду
дую но все же).
Несколько раз было так что все таки пинги начинали появляться, но понять/отследить,
что стало причиной, а по сему и воспроизвести не удалось.

Следующая неприятность которая была выявлена в работе клиентов. На некоторых
станциях необходимо подключение к двум VPN - один PPTP второй L2TP. Выявилось
следующее поведение: если сначала соединяется L2TP клиент то соединение PPTP не
установиться. Если первым устанавливается PPTP то L2TP следом тоже устанавливается.
Мой подозрения что то не так с ассоциацией правил авторизации. Правила разумеется
созданы отдельно под L2TP и под PPTP.
Не знаю на сколько существенен момент, то что все три сервера (PPTP, L2TP, SSL) висят
на одном WAN интрефейсе (так задумано проектными решениями). В документации
ничего криминально на эту тему не нашел.
Еще очень интересует еще следующий аспект. В настройках PPTP сервера есть возможность
выбрать интерфейс с которого производится подключение к PPTP серверу (по крайней мере
так понял данную настройку). А вот в L2TP такого не нашел, есть ли возможность, не понял
он ведь опирается на туннель IPsec, у которого в настройках указывается IP на который
терминируется трафик.

Резюме:
Вопрос 1: как добиться видимости клиентов VPN (в первую очередь PPTP, L2TP/IPsec);
Вопрос 2: как добиться устойчивого подключения клиента к L2TP и PPTP серверу
"размещенным" на одном WA интерфейсе одного DFL, не зависимо от
очередности подключения;
Вопрос 3: есть ли возможность подключаться, конкретно, к L2TP серверу "висящему" на
WAN интерфейсе и из локальной сети, "висящей" на LAN интерфейсе данного DFL
и из внешней по отношению к DFL сети (грубо говоря интернет);

Ниже текущие настройки и правила относящиеся к PPTP/L2TP:

WAN интерфейс:
wan_net:
Name Address No DC UA Groups
------- ------------- ----- ---------
wan_gw 85.236.167.y No <empty>
wan_ip 85.236.167.x No <empty>
wan_net 255.255.255.z No <empty>

Настройки относящиеся к L2TP:
l2tp_net:
Name Address No DC UA Groups
-------------- ----------------------------- ----- ---------
l2tp_1_int_ip 192.168.110.254 No <empty>
l2tp_1_pool_ip 192.168.110.1-192.168.110.253 No <empty>
l2tp_net 192.168.110.0/24 No <empty>


l2tp user:
Name Address No DC UA Groups
------------ ------------- ----- ---------
l2tp_1_user1 192.168.110.1 No <empty>
l2tp_1_user2 192.168.110.2 No <empty>


Конфигурация сервера L2TP:
Property Value
---------------------- -------------------------
Name: L2TP_1_srv
IP: l2tp_1_int_ip
TunnelProtocol: L2TP
Interface: IPsec_1_tun
ServerIP: wan_ip
UseUserAuth: Yes
MPPENone: No
MPPERC440: Yes
MPPERC456: Yes
MPPERC4128: Yes
IPPool: l2tp_1_pool_ip
DNS1: DNS/dns_fors_1
DNS2: DNS/dns_google_1
NBNS1: <empty>
NBNS2: <empty>
AllowedRoutes: all-nets
MemberOfRoutingTable: All
ProxyARPAllInterfaces: No
ProxyARPInterfaces: <empty>


Правила авторизации пользователей сервера L2tp:
Property Value
------------------------- ------------------------------
Index: 1
Name: RuleAuth_L2TP_1_srv
Agent: PPP (L2TP/PPTP/SSL VPN)
ChallengeExpire: 160
AuthSource: Local
Interface: L2TP_1_srv
OriginatorIP: all-nets
TerminatorIP: /wan_ip
LocalUserDB: L2TP_1_User
PPPAuthNoAuth: No
PPPAuthPAP: No
PPPAuthCHAP: Yes
PPPAuthMSCHAP: Yes
PPPAuthMSCHAPv2: Yes
IdleTimeout: 3600
SessionTimeout: <empty>
MultipleUsernameLogins: AllowMultiple (Allow multiple)
AccountingServers: <empty>
BytesSent: Yes
PacketsSent: Yes
BytesReceived: Yes
PacketsReceived: Yes
SessionTime: Yes
SupportInterimAccounting: No
LogEnabled: Yes
LogSeverity: Default

Конфигурация пользователя для сервера L2TP:
Property Value
------------------- ---------------------------
Name: user1
Password: *****
Groups: <empty>
IPPool: l2tp_1_user1
AutoAddRouteNet: l2tp_net
AutoAddRouteMetric: <empty>
SSHKeys: <empty>


pptp_net:
Name Address No DC UA Groups
-------------- ----------------------------- ----- ---------
pptp_1_int_ip 192.168.120.254 No <empty>
pptp_1_pool_ip 192.168.120.1-192.168.120.253 No <empty>
pptp_net 192.168.120.0/24 No <empty>


pptp user:
Name Address No DC UA Groups Comments
------------ ------------- ----- --------- --------
pptp_1_user1 192.168.120.1 No <empty> <empty>
pptp_1_user2 192.168.120.2 No <empty> <empty>


Конфигурация сервера PPTP:
Property Value
---------------------- -------------------------
Name: PPTP_1_srv
IP: pptp_1_int_ip
TunnelProtocol: PPTP
Interface: any
ServerIP: wan_ip
UseUserAuth: Yes
MPPENone: No
MPPERC440: Yes
MPPERC456: Yes
MPPERC4128: Yes
IPPool: pptp_1_pool_ip
DNS1: <empty>
DNS2: <empty>
NBNS1: <empty>
NBNS2: <empty>
AllowedRoutes: all-nets
MPPEAllowStateful: Yes
MemberOfRoutingTable: All
ProxyARPAllInterfaces: No
ProxyARPInterfaces: <empty>
Comments: <empty>

Правила авторизации пользователей сервера pptp:
Property Value
------------------------- -----------------------
Index: 2
Name: RuleAuth_PPTP_1_srv
Agent: PPP (L2TP/PPTP/SSL VPN)
ChallengeExpire: 160
AuthSource: Local
Interface: PPTP_1_srv
OriginatorIP: all-nets
TerminatorIP: /wan_ip
LocalUserDB: PPTP_1_User
PPPAuthNoAuth: No
PPPAuthPAP: No
PPPAuthCHAP: No
PPPAuthMSCHAP: Yes
PPPAuthMSCHAPv2: Yes
IdleTimeout: 1800
SessionTimeout: <empty>
MultipleUsernameLogins: AllowOne (Allow one)
AccountingServers: <empty>
BytesSent: Yes
PacketsSent: Yes
BytesReceived: Yes
PacketsReceived: Yes
SessionTime: Yes
SupportInterimAccounting: No
LogEnabled: Yes
LogSeverity: Default


Конфигурация пользователя для сервера PPTP:
Property Value
------------------- ---------------------------
Name: user1
Password: *****
Groups: <empty>
IPPool: pptp_1_user1
AutoAddRouteNet: pptp_net
AutoAddRouteMetric: <empty>
SSHKeys: <empty>

Правила относящиеся к L2TP
(взаимодействие с другими сетями не показываю, в силу не относящегося к сути, они расположены
в правилах ниже по списку и отрабатываются)

IPPolicy, IPRule L2TP
# Name Action SrcIf SrcNet DestIf DestNet Service
- -------------------------- ------ ---------- ------------------------- ---------- ---------- --------------
1 r50_05_drop_l2tp-all-smb Drop L2TP_1_srv l2tp_1_pool_ip any all-nets smb-all
2 r50_10_allow_l2tpl_to_core Allow L2TP_1_srv l2tp_1_pool_ip core all-nets all_tcpudpicmp
3 r50_20_allow_l2tp_to_l2tp Allow L2TP_1_srv l2tp_net L2TP_1_srv l2tp_net all_tcpudpicmp


IPPolicy, IPRule PPTP
# Name Action SrcIf SrcNet DestIf DestNet Service
- ------------------------- ------ ---------- ------------------- ---------- ----------------- --------------
1 r60_10_drop_pptp-all-smb Drop PPTP_1_srv all-nets any all-nets smb-all
2 r60_20_pptp_to_core Allow PPTP_1_srv all-nets core all-nets all_tcpudpicmp
3 r60_30_allow_pptp_to_pptp Allow PPTP_1_srv pptp_net PPTP_1_srv pptp_net all_tcpudpicmp


PS: конфигурацию дергал через cli, а на форуме шрифты не моноширинные, посему текстовый файл
прикрепил с конфигурацией, скринов бы получилось слишком много.

На мой взгляд на стороне клиентов лучше ставить железку которая сама будет поднимать pptp и l2tp - этим вы решите проблему видимости клиентов и сетей.
В одной конторе я делал три vpn на одном wan - pptp для обычных клиентов (люди могли подключаться только с определенных ip), l2tp - отдельный доступ для другой категории лиц, и поднимал ssl для себя лично, так как приходилось работать из под разных провайдеров (некоторые рубили разные vpn) - так что тут проблем не возникает точно.

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

Сейчас после еще двух дней выходных четко заметил следующую тенденцию:
кто первый подключился к L2TP серверу тот и пингует адрес сервера (192.168.110.254), но только
его, соседей по прежнему не видит. Тот кто подключается вторым пинговать сервер уже не может.
Причем сравнил таблицы маршрутизации на клиентах, подключаются к интернету разными LTE
провайдерами, они практически выглядят под копирку, с разницей выданных IP, таким образом
криминал вроде как получается все таки на стороне сервера.
Я все чаще поглядываю на таблицу маршрутизации DFL, может все таки для моей задачи туда
необходимо делать некую статическую/динамическую запись ?

С сервером PPTP ситуация точно такая же как и с L2TP, первый подключившийся клиент видит
сервер (192.168.120.254), вторая машина уже не пингует сервер, ну и также не видят друг друга.

Сегодня тестировал ssl vpn,ситуация точно такая как и с L2TP и PPTP,с небольшими отличиями.
Тестировал два клиента, оба видят сервер, но не пингуют друг друга. Таблица маршрутизации
на клиентах выглядят как и в случае с L2TP и PPTP, например помимо всего прочего присутствует
такая запись:
192.168.150.0 mask 255.255.255.0 192.168.150.254 If <интерфейс SSL VPN на клиенте Win>
адрес сервера и адрес интерфейса в клиенте правильные.
Народ у кого какие мысли ? Практическое поведение у трех серверов. Не могу продвинуться дальше
пока все клиенты не увидят друг друга.
Help !)

А вот сами подумайте: к одному например pptp серверу на DFL цепляются два клиента - один из города А, другой из города Б. Откуда им знать о существовании друга друга? Как они по Вашему буду друг друга пинговать? Исходя из какой такой логики?
Не стоит забывать - апосля настройки vpn сервера на DFL на клиенте (на конечном удаленном ПК) необходимо прописать маршрут в сетку да DFL.
Ну и правила на DFL написать что бы трафик ходил (ну это все при настройке vpn сервера делается).
Тогда и пинги пойдут до сервака который за железкой.
и что значит "видят" сервер в вашей интерпретации?:)
Кстати - для чего необходима видимость клиентов друг другом?
Повторюсь - правильно было бы все таки организовать туннели между межсетевыми экранами (хоть pptp хоть l2tp - хоть ipsec) и уже в железках разруливать правила хождения трафика и кто кого должен видеть.

Уважаемый asd1979 !
по порядку:
- "Как они по Вашему буду друг друга пинговать?" - "по моему" они очень запросто будут пинговать. Сервер в лице DFL знает все о сетях к нему подключенных,
том числе и о динамически формируемых сетях. Как конкретно он это может делать мне все равно, я не могу себе позволить погрузиться в такие тонкие детали
реализации NetDefendOS (или как ее там в терминологии Clavister). Очевидно что при наличии правила (было выше мной представлено)
Allow L2TP_1_srv l2tp_net L2TP_1_srv l2tp_net all_tcpudpicmp
разрешает хождение трафика между клиентами, настройка (в свойствах пользователя DFL)
IPPool: l2tp_1_user1
AutoAddRouteNet: l2tp_net
сообщает клиенту, что за данным (клиентском) интерфейсе "находится такая то сеть" (в моем случае 192.168.120.0/24) по остальным серверам абсолютно
аналогичные настройки;
- "Не стоит забывать - апосля настройки vpn сервера на DFL на клиенте (на конечном удаленном ПК) необходимо прописать маршрут в сетку да DFL."
как я писал выше из VPN трафик на сторонние сети маршрутизируется вполне штатно и по этому особо вопросов нет. Подчеркну я не задавал вопросов про
проблему хождения трафика из "VPN" в некоторое "Вне", не работает пингование адреса сервера L2TP(в моем случае это 192.168.110.254), это раз
и два это не пингуется, а вернее не только и не столько не пингуются клиенты между собой, но и остальной трафик между ними не ходит. Еще раз подчеркну
под "серваком" я понимаю именно PPTP сервер, его "core" адрес (192.168.110.254), с "сервака который за железкой." все впорядке;

Теперь несколько ответов по тексту ваших вопросов:
- поставить DFL в качестве клиентов перед технологическими станциями невозможно, причины довольно подробно мной ранее описывались, повторяться
не буду;
- видимость клиентов строго через сеть L2TP (а также PPTP и SSL) неотъемлемая часть поставленной задачи. Именно так получат доступ к определенным
сервисам друг друга удаленные клиенты, для которых VPN канал единственная "нить" их связывающая. Т.е. таким образом клиенты получают доступ к сервисам
друг друга, а также к серверам которые находятся за DFL. Таким образом в част VPN DFL должен себя вести как "коммутатор". Замечу, (выше описывал), что
первый подключившийся клиент пингует "core" адрес сервера L2TP сервера. Также периодически один клиент пингует своего соседа, но это бывает непредсказуемо
и только между двумя станциями и никогда между тремя и более.
В данном форуме есть тема, мной ранее созданная, по проблеме разрыва соединения PPTP сервером DFL при простое
Разрыв PPTP соединения при простое. PPTP сервер DFL-260E
viewtopic.php?f=3&t=169947
Для нас это очень критично ! Соединение должно стоять "намертво" и при длительных простоях не рваться, рвет как выяснилось именно со стороны DFL.
На форуме фактически подтвердили, что рвется соединение со стороны сервера т.е. DFL, таким образом остается только непрерывно пинговать клиентом
сервер (DFL) чтобы соединение было поднято. Мной был проведен эксперемент, установлено соединение одним клиентом L2TP ( также проверялся и PPTP)
как я уже говорил, первый подключившийся клиент может пинговать адрес сервера, после запустили пинг и соединение действительно простояло без разрыва
трое суток простоя, пока его не разорвали вручную.

Немного лирики - ранее нам приходилось решать такую задачу, т.е. организацию сети между клиентами VPN средствами Linux и VPN сервера Kerio WinRoute.
Работало как швейцарские цасы в обеих случаях. Сейчас нужно решение на DFL.

PS: при всем уважении, сложилось мнение что вы не читали заданный вопрос и представленный материал по настройкам.

может это из-за настройки пользователя AutoAddRouteNet: pptp_net (если это тоже самое, что в старых прошивках "Networks behind user", то она наверно не нужна, там должно стоять "empty")
надо посмотреть статус маршрутов при подключенном пользователе - должен подыматься только только динамический маршрут на конкретный IP vpn юзера
если поднимается еще маршрут на сеть через IP юзера, то система не будет видеть следующих подключившихся c vpn адресами сети на которую был дан маршрут выше (их динамические маршруты будут ниже в таблице) и как раз так и будет отрабатывать