Проблема оказалась очень неприятной и достойной отдельной темы.
Имеем DFL 860E 2.40.04.08-21457
Шлюз использует в wan два адреса.
На адресе A настроены подключения по VPN (PPTP и L2TP) и многое другое
На адресе B опубликован порт https одного из внутренних серверов.

При подключении по протоколу L2TP/IPSEC перестают отзываться тому же IP порты A и B, в частности, перестает работать упомянутый порт.
Галка "Использовать шлюз в удаленной сети" на компьютере, разумеется, снята.
Это очень, очень неприятно.

При подключении по PPTP все работает нормально (как и без подключения вообще), но PPTP все чаще и чаще не удается применить.

В проверке эффекта участвовали несколько компьютеров с разными версиями Windows (XP, 7, 10)

Есть ли способ спасти ситуацию?

В самом деле, при установлении L2TP/IPSEC подключения появляется правило, согласно которому весь трафик для IP клиента следует пихать в IPSEC, если же снять в настройках IPSEC галку "Dynamically add route to the remote network when a tunnel is established", L2TP VPN просто перестает работать.

И я не могу придумать, как это обойти (((

Ставить еще один шлюз только для VPN или, наоборот, только для тех служб, с которыми надо иметь дело - не хочется. (((

поставить рядом микротик , настроить OPENVPN $-)
поставить комп делее по тексту

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Не исключено, что примерно так и придется поступить.

Но сегодня я весь день дергался в другую сторону. Решил, что если дело в этом правиле маршрутизации, PBR может помочь.
Здесь опыта нет, разбирался.

Сначала попробовал сделать отдельную маршрутизацию для трафика, исходящего с core, надеясь, что там не впишется это динамическое правило.
Облом - пинги прекращаются.

Потом отключил добавление динамического маршрута и сделал отдельную таблицу маршрутизации для исходящего трафика из L2TP сервера.
Соединение не устанавливается.

Потом предположил, что может помочь, если я отключу для L2TP и IPSEC галочку "Before rules". Отключил. Настроил правила. Без PBR соединение устанавливается,
но пинги при этом рвутся - все как было. С PBR соединение не устанавливается, в логах невнятная диагностика, с которой непонятно, что делать, такого вида:

и все.

Поставить микротик, PIX или другой DLink - это очевидный вариант. Но очень не хочется.

Все-таки хочу еще раз поднять тему.

Итак, имеем DFL-260 (или 860), установлено на ip адресе A, имеем клиента на ip адресе B.

Клиент подключается к DFL по L2TP/IPSEC, но ему, сверх того, надо работать с тем же DFL вне туннеля. Например, по HTTP, используя опубликованный на DFL порт какого-то из внутренних серверов.

Кстати, хотя DFL один и тот же, адреса различаются: L2TP устанавливается по адресу A, а работа по другому протоколу идет на адрес A1 (на том же интерфейсе того же DFL).

Не получается. Пока L2TP VPN работает, другого трафика с DFL нет.

Как я понимаю, причина в том, что на DFL при установлении VPN прописывается правило "весь трафик для B пихать в IPSEC".

Прописывание этого маршрута можно заблокировать, но тогда, естественно, не работает L2TP.

Вопрос: нельзя ли решить эту проблему с помощью Policy Based Routing (с которым у меня пока что не очень получается).
Надо, чтобы трафик на B из L2TP шел в IPSEC, а остальной - мимо, через обычный шлюз.
Или "трафик, отправляемый с адреса A1 отправлять через обычный шлюз", полумера, но тоже поможет в моем случае.

Вроде бы PBR именно для таких штучек и сделан?

Знатоки PBR, такое возможно?

Говоря о PBR, давайте сначала обсудим вот что...

У вас опубликованы какие-либо сервисы, которые одновременно работают через два ваших WAN порта? Т.е. часть сервисов отвечает через wan1, другие сервисы через wan2, а третьи через оба?

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Нет, каждый сервис работает через один определенный ip адрес.
VPN работает только на A, там же еще несколько сервисов. И один - на A1.
В принципе я могу все сервисы, кроме VPN, переместить на адрес A1.

Да, и это не имеет отношения к интерфейсам. Адреса разные, интерфейс один (это wan2 в настоящий момент).

Ладно. Сделайте, чтобы у вас оба адреса (А и В) отвечали на пинг снаружи:

http://forum.dlink.ru/viewtopic.php?f=3&t=29666

Серия DFL: Пример настройки PBR от пользователя YuriAM
- ответ по двум WAN портам: http://forum.dlink.ru/viewtopic.php?t=65359&start=14

можете это также сделать для сервиса, к которому дополнительно ломится клиент помимо канала L2TP/IPsec

Вообще, возможно, если сделать PBR для обоих адресов (A,B) для нужных сервисов, все заживет и через один адрес. Но через два точно должно заработать.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

А, кстати, можно один сервис публиковать на двух интерфейсах? Имеется в виду, что это опубликован один и тот же порт одного и того же сервера в LAN.
Этот вопрос не имеет отношения к предыдущему, просто очень интересно и актуально.

В описании Cisco ASA, например, явно указано, что записи об установленных соединениях при маршрутизации имеют приоритет над таблицей маршрутизации. То есть, если я правильно понял, ответные пакеты на соединение, установленное на wan1, будут направлены через wan1, а на wan2 - через wan2. В DFL это тоже так или нет?

Конечно, можно. Это одно из предназначений PBR.

В DFL это не так. Хотя могли бы и сделать. Упростили бы жизнь пользователям и техподдержке. MikroTik, кстати, тоже отвечает без доп. настроек по разным ван портам.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

За что же там цепляется PBR? Или это return routing table? А я-то думал, для чего она нужна.

По поводу пинга... у меня на рабочем DFL, где два интерфейса и на каждом по два адреса, все адреса отвечают на пинги, и сделано это без PBR.
Правда, нет уверенности, что ответный пакет идет с того же интерфейса, на который пришел. )) но это, кажется, волнует не всех.

Как раз на той неделе нечаянно вышел эксперимент на эту тему: в три адреса ответные пакеты (https) шли через другой интерфейс. Два работали нормально, один - нет. И я не смог понять, в чем разница.

По существу проблемы: спасибо, заработало. И, главное, я что-то начал понимать в PBR, хотя явно не все.
И через один адрес тоже работает.

Вот еще одна вещь мне непонятна.
Вы предлагаете для публикации порта использовать такие правила:



У меня так не работает, чтобы работало, приемный интерфейс надо указывать не core, а all.
Почему - не знаю.

Собственно, не обязательно в Routing Rule указывать сервис. Все продолжает работать и для all-services.

Есть дополнительный вопрос.

Этот рецепт работает только для входящих соединений.

А если кто-то из-за DFL, когда клиент с адреса B подключится по L2TP на адрес A, захочет взаимодействовать с чем-то по адресу B - ведь у него не получится.
Точно, пинги, по крайней мере, перестают идти.

Вот это мне решить за счет добавления еще одного Routing rule решить не удалось. Недостаточно я еще понимаю PBR (((

Это, конечно, не так актуально, но все-таки интересно.

PS. Сделать отправку от одного компа в LAN трафика во внешний мир через другой интерфейс - смог. А вот от всей сети в тот же - не получается.
Кстати, правильно ли делать в альтернативной таблице маршрутизации режим Only? Так ведь будут недоступны узлы из сети wan. Не правильнее ли сделать ее First?

Если речь об интерфейсах и адресах с полным доступом в интернет, то это невозможно. Все пинговаться не будут. Либо настроено PBR, либо сети не all-nets.
Из внутренней сети будут все пинговаться.

Доп. адреса лучше навешивать по этой инструкции.
http://forum.dlink.ru/viewtopic.php?f=3&t=114002
Тогда они будут работать неотличимо от родных.

Режим Only или First. Наверное без разницы. Я когда-то немного повозился с ними, не въехал в отличия одного режима от другого и забил на это дело.

Я не могу понять о чем тут речь. Если это для вас важно, опишите понятнее. Если не очень важно, тогда проще не заморачиваться.

Значит, где-то вкралась ошибка в настройках. Тут нет никакой проблемы.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Два интерфейса, оба с полным доступом. На каждом сделан дополнительный адрес. PBR нет. Все 4 адреса пингуются с адреса в инете, не принадлежащего сетям интерфейсов.
Так есть.
Маршрут прохождения ответных пакетов восстановить не представляется возможным, но очень вероятно, что ответ на пинг wan1 возвращается с wan2 через wan2_gw.
Для IP это вроде не криминал.


Здесь речь вовсе не о навешивании доп. адресов, а о публикации порта. Не работает у меня публикация, когда используется core, получается только с any.

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

Опишу понятнее.
Есть DFL с внешним адресом A, у нее lan и wan интерфейсы. Есть удаленный маршрутизатор с адресом B, на каком-то порту у него открыт сервис C.
Клиент из-под маршрутизатора B подключается по L2TP к DFL.
Другой клиент, из lan DFL, хочет воспользоваться сервисом C.
Но его трафик запихивается в IPSEC туннель, поэтому облом.
В моем эксперименте вместо доступа к сервису был простой пинг адреса B и оно не работало, пока установлен L2TP.

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

Спасибо за помощь, то, что сегодня получилось - это очень важно для нас.

Наверняка этому есть логическое объяснение. Но в данном контексте не стоит на этом циклиться.

Но DFL так не делает. Опять же, ответ выше по тексту.

Потому я и советую навесить адреса должным образом, чтобы все настройки работали как обычно. Без any.

Вроде понял. Опять же это можно решить через PBR, сделанного для сервиса С на адресе В. Не шибко красиво - этакий маленький костыль получится.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.