Используется последняя версия прошивки.

Схема маршрутизации траффика:
Домашний компъютер в локальной сети провайдера, для доступа в Интернет им используется "прозрачный прокси" -->
Интернет -->
wan-интерфейс DFL-1600. Он VPN-сервер, он же маршрутизатор и файервол.

Проблема::
настроил pptp-соединение. При попытке установить подключение с домашнего компъютера соединение устанавливается 3-4 раза последовательно (подключения частые - подключился/отключился), потом установка соединения зависает на етапе: проверка имени пользователя и пароля. Анализ траффика выявил следующие особенности:
1) на запрос конфигурации соединения компъютером (PPP LCP Configuration Request) удаленный сервер не реагирует никак, хотя должен слать PPP CHAP LCP Configuration Ack/Reject.
2) в свою очередь сервер шлет Call-Disconnect-Notify по истечению некоторого времени, что характерно для случаев подвисания pptp-клиента (ПК), то есть в случае, когда от него не получен ответ.
Самое интересное, что при изменении IP-адреса компъютера в локальной сети опять получаешь 3-4 возможности подключится. Если изменить IP-адрес на первоначальный, то подключится все равно не возможно, разве что через некоторое время, и только в случае переконфигурации сервера. Если конфиг сервера не менять, то нельзя подключится даже по прошествии суток.
Пробовал подключатся с другого провайдера, на выходе в Интернет стоит оборудование Микротик, ничего больше не знаю. Результаты похожи на описанную выше ситуацию.

Про конфигурацию pptp-сервера:
1) pptpBeforeRules включено
2) результат один и тот же при использовании как источника авторизации локальной базы или RADIUS-сервера.
3) первоначально грешил на сигнатуры вторжений, но на d-linke только заводские.
4) в логах по факту подключения можно обнаружить только сообщение pptpBeforeRules -- conn open или conn close

Еще:
Намучившись с pptp решил установить l2tp ipsec один в один как по мануалу, благо, конфигурация сети у меня такая же, как и в примере. Wan- интерфейс пингуется, а клиент VPN зависает на фазе "Установка соединение". С компъютера уходят пакеты ISAKMP Identity Protection, на d-linke в логах опять же можно видеть ipsecBeforeRules conn open или conn close. NAT-T включаен в режиме "если поддерживается и НАТируется" Возможно, это часть все той же проблемы.

Какие конкретно настройки используются?
Что в логах?

_________________
Форум не подразумевает под собой быстрый ответ, хотите быстрый и квалифицированный ответ - звоните в техподдержку компании D-Link 8-800-700-5465

Настройки PPTP
СЕРВЕР


ПРАВИЛО АУТЕНТИФИКАЦИИ


Настройки L2TP IPSec
СЕРВЕР


IPSec-туннель


ПРАВИЛО АУТЕНТИФИКАЦИИ


IP-правила


Упрощенная топология сети


PptpBeforeRules, IpsecBeforeRules, L2TPBeforeRules включено

В логах при попытке соединения появляется:
PptpBeforeRules/IpsecBeforeRules (соответственно) --- conn open, а по прошествии некоторого времени conn close, (что естественно)
Больше ничего относящегося к делу. Может, у меня в логах чтото не включено.
Все 8 уровней логирования в MemLoge выбраны.
Здесь похожая проблема - во всяком случае, у меня такие же логи и такая же ошибка на встроенном в виндовс VPN-клиенте. В качестве клиентской машины использовал XP и Seven
viewtopic.php?f=3&t=132049

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

_________________
Сообщения в PM игнорируются, задавайте вопросы на форуме.

Вот так выглядит сессия. То, о чем я писал в самом первом сообщении, только более наглядно. После PPP LCF Configuration Request как раз и идет от сервера pptp запрос на аутентификацию -- PPTP Challenge, как то так.. точно не помню.
Фаза LCF Configuration Request предусматривает, что обе стороны договариваются о параметрах соединения - одна сторона высылает предложения, другая принимает их (ack) или отвергает (reject). Здесь же нет ни того, ни другого. Соответственно, сервер думает, что я не прислал ему предложений, и поэтому шлет мне Call-Disconnect-Notify вместо Challenge, как было бы в случае, если бы клиенты договорились о параметрах.
То есть в логах в принципе ничего не может быть касательно аутентификации.