НА DFL, который раздает Надо запросы в all-nets NAT`тить, остальные allow, на dfl который принимает все правила allow

Спасибо, если я вас правильно понял, то правила должны быть такими:
На раздающей (в доп. папке):
1 drop_smb-all Drop ipsec_tunnel workshop_lan wan all-nets smb-all
2 allow_ping-outbound NAT ipsec_tunnel workshop_lan wan all-nets ping-outbound
3 allow_ftp-passthrough NAT ipsec_tunnel workshop_lan wan all-nets ftp-passthrough
4 allow_standard NAT ipsec_tunnel workshop_lan wan all-nets all_tcpudp

На доп.офисе:
1 allow_standard_out Allow lan lannet ipsec_tunnel all-nets all_tcpudp
2 allow_standard_in Allow ipsec_tunnel all-nets lan lannet all_tcpudp

Примерно так.

Благодарю всех за помощь, отдельное спасибо Сергею Васильеву, все заработало, не думал я что придется правила создавать на дфльке в допофисе, думал что в ipsec идет все подряд, ан нет. Вообщем заработало так как я хотел, осталось подрихтовать маршруты и полностью убрать выход в инет с доп. дфли.
Пасибо

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

с прошивкой 1.50b02 для DI-804HV эта схема "раздача впн-сервером на di-804hv впн-клинтам 'интернета'" работает, проверял лично, даже больше, работает таблица маршрутзации, т.е. не только в сторону wan, но и по локальной сети, если там есть свои шлюзы (отличные от того к кому подключился впн-клиент, но обмануть впн сервер и попытаться с клиентской машины отправить на другой шлюз в локальной сети за роутером трафик не удасться, т.е. отправка идёт всегда на впн-сервер, а дальше маршрутизируется уже по его правилам, если он о сети не знает, то путь только в WAN).

зы. не проверял работает ли фаерволл, если да, то просто класс, а так возможно придётся отказаться от такого нововведения, чтоб в инет никто не уходил... но думаю что работает, протестировать надо


...вопрос к службе поддержки: виды интерфейсов в правилах фаерволла "WAN", "LAN", "*" что означают в этой новой прошивке 1.50b02?
WAN -- это и wan-phys и wan-vpn одновременно
LAN -- это только "лан" или ещё и впн клиенты
выяснять экспериментально некогда, может от вас быстрее узнаю


оффтоп
пожелание: метрики в маршрутах может в новой прошивке вернёте, гибкость больше будет когда успешно заработает RIP //они были в первых ревизиях pre 2.0 кажется
и ещё одно пожелание, может в таблице маршрутизации может сделать возможность, чтоб можно было указывать интерфейс назначения, просто физический или впн или лан и т.п., в случае когда адрес неизвестен, когда он может быть динамическим.... ну это так, вдруг бедет не сложно... с метриками я может и сам их смогу "вбить в железку", мока не пытался, но если поковырять старую прошивку узнать какие это были переменные и "самому их туда отправить", хотя лучше чтоб в вёб-мордочке это было изночально... раньше оно было

...и чтоб все там 32 правила можно было набить за раз, а не по одному добовлять и ждать пока ребутнётся железка... хотя сделали скрипт молодцы!!! пусть сложней разбираться, зато гибкость в прошивке для создателей есть, один раз отладили и навеки

Это нормальная ситуация, мы обычно предупреждаем об этом, для этих целей мы рекомендуем использовать PPTP клиент-сервер, а передачу данных lan to lan по IPSec

Я конечно понимаю что это "нормально", но всетаки можно углубиться немного в проблему и рассказать из-за чего конкретно происходит такое, если вы уже сталкивались с подобной проблемой? Может она решаема и в данном конфиге?

Мне тоже не совсем ясно, как можно назвать нормальной ситуацию, когда что-то не работает.

Как вы знаете у тоннеля всегда MTU меньше чем у физического интерфейса, отсюда и возникают проблемы, пакеты фрагментируются, но не все собираются, так же на некоторых пакетах стоит флаг не фрагментировать, эти пакеты совсем отбрасываются. вот отсюда и возникает ситуация с недоступностью некоторых ресурсов, у тоннеля PPTP/L2TP, MTU может уступать физическому интерфейсу всего на 8 (физический 1500, PPTP/L2TP/PPPoE обычно при таких настройках становиться 1492), поэтому обычно проблем с этими интерфейсами не возникает. Попробуйте уменьшить MTU на удаленных компьютерах.